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

[ryandesign]

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]

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

[Youw]

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]

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:

hidapi/BUILD.autotools.md

Lines 48 to 51 in c19ae12

	./bootstrap # this prepares the configure script
	./configure
	make # build the library
	make install # as root, or using sudo, this will install hidapi into your system

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
 ```

[Youw]

Good point, I'll update the doc.

[Youw]

Thanks.