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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2021-04-09 09:30:14

>> 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.

I'd fully agree with that.

The problematic situation can only occur, when a folder is added to the 
include paths, which contains an extensionless file named "version". I 
checked gnuplot and they have a "version.h" which does not trigger this 
problem. Furthermore IMO it is bad practice to use such a common name 
and not "namespace" it in an include folder, e.g. `#include 
<gnuplot/version.hpp>` or similar.
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.

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.

--> My proposal is to do nothing in Boost. If the issue is raised again, 
we could consider adding a comment on that line, as likely the compiler 
will mention it.