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.