Build failure with in-source autotools build on case-insensitive filesystem with C++20-capable compiler #621

New issue

Closed

opened 2023-09-03 09:27:17 -05:00 by ryandesign · 5 comments

ryandesign commented

2023-09-03 09:27:17 -05:00

(Migrated from github.com)

In file included from test.cpp:18:
In file included from /opt/local/include/fox-1.6/fx.h:31:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/c++/v1/math.h:309:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/c++/v1/type_traits:420:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/c++/v1/cstddef:37:
../version:1:1: error: expected unqualified-id
0.14.0
^

This is because C++20 has a header called version which is automatically included by various system headers, but your project has a file called VERSION in its root directory. An in-source autotools build will add the flag -I. to find the generated config.h file, but this will also cause the VERSION file to be used instead of the version file.

Note this problem occurs in any C++ mode, not just C++20 mode, as long as the compiler has C++20 compatibility and therefore has the version header.

Doing an out-of-source build does work. I am aware that the autotools build system is deprecated. I have not tested in-source nor out-of-source cmake builds.

When doing an in-source build using the autotools build system on a case-insensitive filesystem (for example, most Macs) when using a compiler that is aware of C++20, the build fails, for example on macOS 12: ``` In file included from test.cpp:18: In file included from /opt/local/include/fox-1.6/fx.h:31: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/c++/v1/math.h:309: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/c++/v1/type_traits:420: In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/c++/v1/cstddef:37: ../version:1:1: error: expected unqualified-id 0.14.0 ^ ``` This is because C++20 has a header called `version` which is automatically included by various system headers, but your project has a file called `VERSION` in its root directory. An in-source autotools build will add the flag `-I.` to find the generated config.h file, but this will also cause the `VERSION` file to be used instead of the `version` file. Note this problem occurs in any C++ mode, not just C++20 mode, as long as the compiler has C++20 compatibility and therefore has the `version` header. Doing an out-of-source build does work. I am aware that the autotools build system is deprecated. I have not tested in-source nor out-of-source cmake builds.

ryandesign commented

2023-09-03 09:36:36 -05:00

(Migrated from github.com)

More about this problem in this llvm bug report if you're interested.

More about this problem in [this llvm bug report](https://bugs.llvm.org/show_bug.cgi?id=42540) if you're interested.

Youw commented

2023-09-04 04:06:00 -05:00

(Migrated from github.com)

I have not tested in-source nor out-of-source cmake builds.

For completeness of the picture I'd be happy to see results of testing the in-source CMake build.

But I do not support changing a great/simple name of a file so that deprecated build system works in non-recommended scenarios.

> I have not tested in-source nor out-of-source cmake builds. For completeness of the picture I'd be happy to see results of testing the in-source CMake build. But I do not support changing a great/simple name of a file so that deprecated build system works in non-recommended scenarios.

ryandesign commented

2023-09-04 07:06:54 -05:00

(Migrated from github.com)

The good news is that cmake builds, whether in-source or out-of-source, don't seem to have the problem. Even with an in-source build, cmake doesn't add a -I flag for the root directory because cmake doesn't put generated headers there. So this is a uniquely autotools problem which will go away when you remove that build system.

If the "non-recommended scenario" you're referring to is doing an in-source autotools build, then it could suffice to update the documentation to recommend an out-of-source build. Currently, the documentation shows how to do an in-source build:

github.com/libusb/hidapi@c19ae126d8/BUILD.autotools.md (L48-L51)

An out-of-source build would be:

--- BUILD.autotools.md.orig	2023-09-04 06:24:45.000000000 -0500
+++ BUILD.autotools.md	2023-09-04 06:25:14.000000000 -0500
@@ -46,7 +46,9 @@
 
 ```sh
 ./bootstrap # this prepares the configure script
-./configure
+mkdir build
+cd build
+../configure
 make # build the library
 make install # as root, or using sudo, this will install hidapi into your system
 ```

The good news is that cmake builds, whether in-source or out-of-source, don't seem to have the problem. Even with an in-source build, cmake doesn't add a `-I` flag for the root directory because cmake doesn't put generated headers there. So this is a uniquely autotools problem which will go away when you remove that build system. If the "non-recommended scenario" you're referring to is doing an in-source autotools build, then it could suffice to update the documentation to recommend an out-of-source build. Currently, the documentation shows how to do an in-source build: https://github.com/libusb/hidapi/blob/c19ae126d8856b55af34d64ee11641920475961c/BUILD.autotools.md?plain=1#L48-L51 An out-of-source build would be: ````diff --- BUILD.autotools.md.orig 2023-09-04 06:24:45.000000000 -0500 +++ BUILD.autotools.md 2023-09-04 06:25:14.000000000 -0500 @@ -46,7 +46,9 @@ ```sh ./bootstrap # this prepares the configure script -./configure +mkdir build +cd build +../configure make # build the library make install # as root, or using sudo, this will install hidapi into your system ``` ````

Youw commented

2023-09-04 07:25:25 -05:00

(Migrated from github.com)