> On Oct 29, 2016, at 5:23 PM, [email protected] wrote: > > On Sun, Oct 23, 2016 at 6:06 PM John Ralls <[email protected] > <mailto:[email protected]>> wrote: > > > On Oct 23, 2016, at 5:02 PM, [email protected] > > <mailto:[email protected]> wrote: > > > > Hi list, > > > > The first bugfix release of Sierra, 10.12.1 is almost out so I'll soon be > > doing that yearly dance of upgrading my Mac and Xcode, wiping my jhbuild > > tree, and rebuilding everything, fixing build bugs along the way. > > > > I'm motivated to implement changes in gtk-osx-build that will make that > > dance a little easier and shorter! > > > > One thing that I spend a lot of time and frustration on every year is > > building those modules that aren't really related to GNOME, like gnutls and > > the rest of the crypto stack needed to build glib-networking, etc. One > > thing I've dreamed about for a long time is using Homebrew to install > > those, through jhbuild's <sysdeps> facility. I don't think that's really > > realistic as such, for two reasons: 1) it's difficult to get Homebrew to > > cooperate with install trees that aren't in /usr/local, and 2) there's no > > reverse lookup for Homebrew packages by files that they provide [1]. > > > > But, I think it would work fine to use Homebrew to install standalone build > > tools, such as pkg-config, xz, bison, flex, etc. They wouldn't have to be > > in the jhbuild tree, just in the path, and they usually wouldn't need to be > > included in an app bundle. > > > > This would save a lot of time and allow us to offload a lot of maintenance > > work to the much larger Homebrew community, as well as help us keep > > up-to-date versions of those dependencies. > > > > It could be just an extra step in the instructions / scripts for setting up > > gtk-osx-build that installs a bunch of Homebrew packages pre-emptively, or > > we could write a <sysdeps> thing that installs Homebrew packages as needed > > when building modules. > > > > Homebrew works on 10.5 and up, although 10.5–10.9 are supported only on a > > best-effort basis, and you can get it to work on 10.4 using a fork [2]. > > > > Would there be any interest in this? Any problems that I'm missing? > > > > [1] > > http://superuser.com/questions/781693/how-to-determine-which-brew-package-provides-a-given-file > > > > <http://superuser.com/questions/781693/how-to-determine-which-brew-package-provides-a-given-file> > > [2] https://github.com/mistydemeo/tigerbrew > > <https://github.com/mistydemeo/tigerbrew> > > Phil, > > I guess I don't see the point. All of what you're suggesting is in > bootstrap.modules, and that takes only a few minutes to build on a recent > (meaning capable of updating to Sierra) Mac. You can do it once to somewhere > on the path (I put it in ~/.local) and it will be used for all of your other > builds. The only wrinkles I get from that are that jhbuild doesn't know to > look there for the xml catalog and a few packages (e.g. Guile) need to have > libltdl in the bundle with them. Compared to the time needed to build even > meta-gtk-osx-core, never mind a major program (never mind WebKit, which takes > over an hour on a late 2013 Mac Pro) it's pretty trivial. > > That's true. I tend to think, the fewer modules under maintenance in > gtk-osx-build, the easier it is for us to keep things up to date. But I > suppose I could make a much larger dent by figuring out how to use Homebrew > recipes for non-GNOME libraries... > > Any other ideas for changes I could implement while doing the Sierra dance > that would ease maintenance?
It's time to go through the whole stack again... I've also discovered recently that Webkit 1.10 when built with Xcode 7 or 8 segfaults when I try to feed it Javascript graph stuff in GnuCash. My first pass at debugging wasn't able to see inside the Javascript interpreter. It might be worthwhile to see if there's any way we can use the Gnome modulesets. Alison Lortie did a lot of work on them a couple of years ago to get them to work with one of the BSDs (I forget which), and Darwin is technically a BSD. If that could be made to work it would be more of a work-saver than integrating with Homebrew. Regards, John Ralls
_______________________________________________ Gtk-osx-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
