select_stdlib_config.hpp including <version> vs <VERSION> on OS X
Hello, A casual boost user and abuser here. Some specifics on my OS OS X Big Sur 11.2 Xcode 12.4 Compiler clang : Apple land version 12.0.0 Boost 1.73 - forward When select_stdlib_config.hpp is included it gets to this initial code to include <version> ... #if defined(__cplusplus) && defined(__has_include) # if __has_include(<version>) // It should be safe to include `<version>` when it is present without checking // the actual C++ language version as it consists solely of macro definitions. // [version.syn] p1: The header <version> supplies implementation-dependent // information about the C++ standard library (e.g., version number and release date). # include <version> ... 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 Cheers, Allen Sanderson SCI Institute University of Utah
Gesendet: Donnerstag, 08. April 2021 um 19:55 Uhr Von: "Allen Sanderson via Boost" <boost@lists.boost.org> An: boost@lists.boost.org
When select_stdlib_config.hpp is included it gets to this initial code to include <version>
... #if defined(__cplusplus) && defined(__has_include) # if __has_include(<version>) // It should be safe to include `<version>` when it is present without checking // the actual C++ language version as it consists solely of macro definitions. // [version.syn] p1: The header <version> supplies implementation-dependent // information about the C++ standard library (e.g., version number and release date). # include <version> ...
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
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. Best Mike
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.
Gesendet: Freitag, 09. April 2021 um 11:30 Uhr Von: "Alexander Grund via Boost" <boost@lists.boost.org> 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 <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
On 9/04/2021 10:05 pm, Mike wrote:
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>.
Which is entirely the wrong thing to be doing. The "libfoo" directory should be under an "include" parent directory, and *that* is what should be added to the include path. Otherwise all the extraneous files in the root are going to pollute the include path. While you could frequently get away with that in the past, C++'s poor decision to use include files without extensions and GNU's poor decision to use documentation files without extensions are inevitably on a collision course to failure. #include <license> is another name that won't cause any problems now, but is potentially risky if the standard ever adopts some similar concept. It's just developers being lazy.
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
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.
Thanks, I added my findings to that for others to find. Maybe Boost.Config can put a comment on the include line with a reference to that issue, so others know where to look for solutions and a comment above with something like "If this fails, make sure there is not custom file called 'version' in your include paths"
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 <boost@lists.boost.org> 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
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
Am 09.04.21 um 19:13 schrieb Allen Sanderson via Boost: 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 :)
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 <boost@lists.boost.org> 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
participants (5)
-
Alexander Grund -
Allen Sanderson -
Gavin Lambert -
John Maddock -
Mike