Fix Boost modules with libraries

[bredelings]

This PR suggests that meson temporarily revert some changes to the Boost dependency, pending a future fix.

As discussed in issue #15154, these changes don't work on Debian, Ubuntu, Red Hat, Arch, Gentoo, and Alpine. That is a lot of Linux distributions.

With this PR, some systems fail to configure until meson.build is edited. Without the PR, some systems incorrectly configure and then fail to build until some packages are installed. Neither is great -- what to do? 🤷‍♂️

[bredelings]

Another approach would be to special-case Boost.system instead of Boost.python. This might work better since the list of library-modules-that-became-header-only should be short and not change very fast.

[eli-schwartz]

As discussed in issue #15154, these changes don't work on Debian, Ubuntu, Red Hat, Arch, Gentoo, and Alpine. That is a lot of Linux distributions.

It is a bit ironic you say that, given your PR doesn't work on Arch (or macOS), and Fedora has boost 1.83, Gentoo has boost 1.88, and Ubuntu has boost 1.88 as well. So both places boost 1.89 is installed in CI, the

revert of changes that don't work

is what breaks the CI. (It is expected that it would break the CI. The CI upgrading to boost 1.89 and breaking, is the original reason these changes were originally made.)

And...

Another approach would be to special-case Boost.system instead of Boost.python. This might work better since the list of library-modules-that-became-header-only should be short and not change very fast.

That would, I believe, be a more accurate summary of "As discussed in issue #15154" than claiming the summary "these changes don't work". Yes, I acknowledge that the real difference is that some people think issue #15154 proves one thing, while others believe it proves something else at a 90 degree angle.

...

But... at the end of the day, CI doesn't lie. It can't lie, because it's the arbiter of truth: CI can't be made to start failing, because that makes CI worthless for detecting anything else, which means it is impossible to merge any PRs at all as it becomes exceedingly difficult to tell what changes are valid to make.

This PR cannot be merged until CI passes. If someone were to merge it anyway, it will be unconditionally reverted directly from git master pursuant to the contributing docs at https://mesonbuild.com/Contributing.html#a-green-ci-run-is-mandatory-for-merging

Please try to update this PR to use the method that we already discussed in the issue. In your words:

Another approach would be to special-case Boost.system instead of Boost.python. This might work better since the list of library-modules-that-became-header-only should be short and not change very fast.

And in my words:

Meanwhile the ONLY solution I can see for meson is for meson to contain a version-by-version list of boost modules that are exempt from needing a library component. Whenever a boost module transitions from being a library to being header-only, we add a min version. Whenever a boost module transitions from being header-only to being a library, we add a max version. Yes, this means boost users will need to wait for a new version of Meson every time boost upstream changes its approach.

Given that this was already discussed before the PR was opened, I cannot at all see us accepting a simple revert "pending a future fix". Especially if the PR description agrees that it's not a real fix and calls itself "temporary".

Even if the contribution docs didn't prevent a simple revert from being merged, the goal is to get the change into a release, not into git. And I won't backport a change into a stable release that fixes one use case and breaks another -- if it's going to be broken anyway, better that the shape of the breakage itself stays the same until there's a real fix, rather than toggling back and forth. At least then one could predictably pin their version. And that means there would be no urgency to merge a simple revert, and we should first try to figure out a proper fix.

I would love to see this fixed, and I would be happy to backport it to stable. But, we do need that future fix to be the one that gets merged.

[bredelings]

I'll plan to work on that approach as I have time.

However, it seems part of the problem is that

• your CI contains tests that you want to continue to work -- so you don't want to change the tests to remove boost "system" from being a "module"
• but on the other hand, there are no CI tests that assess the failure that I'm seeing. That is, there are no tests that check that boost fails to configure when it will fail to link.

So, there are two types of failures here, and the current tests only check for one kind of failure. So, yes, CI can definitely lie. (Or, more accurately, CI doesn't directly speak -- it must be interpreted.)

That said, I think the approach I outlined can solve my problem and also pass the existing tests.

[eli-schwartz]

Thanks, looking forward to reviewing it. Again, I agree the current situation isn't great.

And yes -- adding more tests to cover more cases is always good. Removing tests once they start failing is not so good, though it can technically happen if for some reason it's deemed there is no other choice, and has the advantage of not rendering status checks useless overall. :D