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

From: Mike (mike.dev_at_[hidden])
Date: 2021-04-09 10:05:33

> Gesendet: Freitag, 09. April 2021 um 11:30 Uhr
> Von: "Alexander Grund via Boost" <boost_at_[hidden]>
> An: boost_at_[hidden]
>
> 
> >> 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 <libfoo/libfoo.hpp>

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