> On Oct 23, 2016, at 5:02 PM, philip chimento gmail com 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
> [2] 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
|
