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

Hello, Thanks for the replies. I had not found the issue in my search as I knew I could not be the first to encounter this issue. After reading the issue and the links I agree that it is not a boost problem. But a new paradigm that projects are going to need to adapt to going forward. With the <version> now being a C++20 file there is going to be lots of file renaming across many projects in the near future as I did a find file for VERSION across several software projects I use locally and it is quite prevalent. Glad I only actively develop on a few projects. Thanks and Cheers, Allen Allen Sanderson SCI Institute University of Utah

On Apr 9, 2021, at 4:09 AM, John Maddock via Boost wrote:

...

The issue is that many projects (gnuplot, builtbot, and others) have a VERSION file in their top level src directory. On a traditional Linux system the case sensitivity would make sure the right file is included. However, many/most OS X file systems are case insensitive. As such, the project's VERSION file gets included instead. And does not compile.

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

We have a recurring issue filed on this here: https://github.com/boostorg/config/issues/345

So while I agree it's annoying, and I feel your pain, the fact is that <version> is a std lib header, and a very useful one (for us at least), so while you might have hit this issue here first, it's likely to become more and more common over time.

Best, John.

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Alex, You are correct. For the project I am working on this issue is entirely “our” fault as in the top level CMakeLists.txt file the following was included: INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}) That should have never been included (pun intended). I looked at some other projects with a VERSION file. Some are in a directory with header file files. Those will probably have some build issues going forward. Thanks for everyone’s help and guidance. Cheers, Allen

On Apr 9, 2021, at 11:31 AM, Alexander Grund via Boost wrote:

Am 09.04.21 um 19:13 schrieb Allen Sanderson via Boost:

...

Hello,

Thanks for the replies. I had not found the issue in my search as I knew I could not be the first to encounter this issue. After reading the issue and the links I agree that it is not a boost problem. But a new paradigm that projects are going to need to adapt to going forward. With the <version> now being a C++20 file there is going to be lots of file renaming across many projects in the near future as I did a find file for VERSION across several software projects I use locally and it is quite prevalent. Glad I only actively develop on a few projects. FWIW: No renaming is needed, if the file is not added to the include path. And IMO only the minimal required amount of stuff should be there, so having that file in the include path is already a bad sign. It also means that less projects may be affected as you fear :)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost