Re: [boost] select_stdlib_config.hpp including <version> vs <VERSION> on OS X

Gesendet: Freitag, 09. April 2021 um 11:30 Uhr Von: "Alexander Grund via Boost" An: boost@lists.boost.org

...

...

I have no solution to the issue other than I renamed our project’s VERSION file for the time being. However, I wanted to raise the issue as I noticed it when moving to 1.75 and backtracked out that it was a recent changed starting with boost 1.73 My personal opinion on this: Boost could put this include behind a c++ version check to reduce the number of

collisions for now (I'd guess compilation with c++20 is not yet a common scenario), but I think this is an issue that has to be raised with the respective projects.

<version> is a c++20 standard header that might not only be included by more and mmore 3rd party libs, but also by any other standard library header. So this conflict is bound to become more and more common.

[...]

So I'm wondering how exactly this triggers an issue "with many projects". Which projects are exactly affected? As mentioned gnuplot cannot be affected and builtbot seems to be a Python project, so their VERSION file should not end up in the include path of a C++ application either.

I haven't checked the concrete projects, so would be curious too, but what I'd expect from the description is the following (or similar) structure: <libfoo-root> - libfoo - libfoo.hpp - src - src1.cpp - src2.cpp - VERSION <- this isn't a c++ file - ... and because the suggested include scheme is #include the search path that gets added to the parent project is -I<libfoo-root>. But again: pure speculation, because I have seen several projects following that structure and even boost does it that way when building the superproject (it just doesn't have a VERSION file in its root). Still, banning the inclusion of a standard library header is imho not a realistic course of action and in particular is not a solution to the unerlying problem which is rooted in libfoo and not boost:

And having <version> added to the C++ standard means, that it is (IIRC) fully UB to add such a folder to the include paths and Boost triggering this might well serve as a warning to project authors to reconsider this.

Completely agree. Best Mike