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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk