glib: enable both shared and static libs

[jeroen]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

When we switched to meson/ninja we lost the --enable-static flag. This re-enables building both shared and static libs.

We need these for building R packages. Thank you!

[bayandin]

See #52389 for the previous discussion about static libraries

[jeroen]

@bayandin thanks I was not aware of that discussion. We need static libraries to build R packages (https://www.r-project.org/). I hope it can be reconsidered (mostl homebrew formulae include static libraries these days)?

[carlocab]

Does this affect the ability to build all R packages or only a subset of them? How have you been building R packages without this?

[jeroen]

It affects important R packages that deal with graphics and imaging, mostly via cairo and librsvg and imagemagick.

To build these packages I have been running an fork of homebrew-core, which has an old version of glib that still had the static libs but I would like to go back to the main homebrew-core tap so that we get updates and support arm64.

[fxcoudert]

I'd like @tschoonj's opinion on that. I don't think switching glib on its own is very useful, probably we want to either ship all gtk-related formulas with static libraries, or not.

Downside of shipping static libraries for everything is license (as commented in the issue linked), and disk size: all the gtk libraries are heavy

[tschoonj]

I don't really have a strong opinion on this. If you are ok with doubling the installation size and the bottle build time for this formula and any other formulas @jeroen needs, then so am I.

[jeroen]

I don't think switching glib on its own is very useful, probably we want to either ship all gtk-related formulas with static libraries, or not.

Actually for many purposes fixing glib itself would be very useful, because glib is a hard dependency of important things like cairo, librsvg, and imagemagick. We don't use any gtk+ in R, but we really can't get around glib for many R packages.

The size doesn't seem too bad, it's going from 4.5M to 6.5M (bottle size).

[carlocab]

While we're discussing this, and since this will need to be re-run anyway if it's going to get merged:

Can you make the --default-library=both flag part of the args array instead of inserting it in the system "meson" line?

Don't do this just yet, though, as you'll need to eventually rebase against fixes in this PR: #68039

Not to mention probably give gdal another revision bump...

[jeroen]

I have rebased this; the remaining failure seems like an unrelated network error in one of the reverse dependencies.

[carlocab]

Why didn't you put --default-library=both in the args array?

[jeroen]

Oh sorry I missed that, I quickly did git rebase before heading off for nye. I can change it.

[jeroen]

The reverse check error is still the same unrelated random network failure in the test glyr test.

[jeroen]

Should I trigger another rebuild to see if the random network failure in one of the dependent tests is gone? I'm a bit reluctant because each build seems to take 10hours per platform, and the test failure is obviously not related to this PR.

[carlocab]

No, I think this is fine. Personally, I'm fine with this change, but I'm waiting to see if there are objections to it.

If no one else responds, just post another comment here towards the end of the week. (Sorry, Homebrew maintainers have a lot on their plates.)

[BrewTestBot]

@fxcoudert has triggered a merge.

[jeroen]

Thanks all!