Fix Boost modules with libraries #15197
Conversation
|
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. |
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
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...
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:
And in my words:
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. |
|
I'll plan to work on that approach as I have time. However, it seems part of the problem is that
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. |
|
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 |
|
So right now detecting boost is completely broken. If there's no way to keep CI green here, it should at least be in release notes. Stupid question, why can't the new behavior of looking only for headers be applied to a small set of modules? That would at least make the situation more bearable. |
CI is green if you don't care about Debian. :) (Or you make sure to install all boost packages on Debian. It's a matter of an incomplete package splitting causing misdetection.)
Not a stupid question. That is exactly the behavior I suggested a month ago as the "only" solution, in #15154 (comment) The original change simply didn't anticipate that Debian would break the naive approach. |
This has nothing to do with Debian specifically. Detecting boost is broken on Debian, Ubuntu, Red Hat, Arch, Gentoo, and Alpine. The underlying idea that a library will be present if its headers are present is simply not true on any of the distributions I checked except Suse. CI is green because there are no tests that test the problem.
I am hoping to do this, but haven't had time yet. |
bredelings
force-pushed
the
fix-boost
branch
from
f5c473a to
35ad57d
Compare
| # Use one without a library dependency and one with it. | ||
|
|
||
| linkdep = dependency('boost', static: s, modules : ['thread', 'system', 'date_time']) | ||
| linkdep = dependency('boost', static: s, modules : ['thread', 'date_time']) |
There was a problem hiding this comment.
Commit message should probably say "tests: ..." if it is test-only.
But this change shouldn't be made at all, I think. We want to test that the (eventual) new handling correctly handles cases where existing meson.build files still specify Boost.system. Otherwise we won't be exercising the proposed new codepaths.
There was a problem hiding this comment.
Ah, and Bionic has saved us by explicitly failing. Its boost is old enough that libboost_system.so isn't a stub at all, it has genuine required symbols and the testcase fails to compile due to not asking for system.
It... I keep saying this and I'm not sure why it keeps needing to be said. For boost 1.88, a library WILL be present if its headers are present, on Red Hat, Arch, Gentoo, and Fedora. For boost 1.89, Suse cannot have a library be present if its headers are present, because there is no library for Boost.system. By the same rule, neither can the other four. Debian is the ONLY distribution (and Ubuntu is a Debian clone so it does not qualify to be listed separately) where it is not true that a library will be present if its headers are present, as a general rule. |
3 participants
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.buildis edited. Without the PR, some systems incorrectly configure and then fail to build until some packages are installed. Neither is great -- what to do? 🤷♂️