Paul Eggert wrote:
> > we have no way of portably setting the compiler flags
> > if available.
>
> That's fine, but Gnulib does have a portable way to see whether the C++
> compiler works properly with <stdckdint.h>. Namely, compile a little
> <stdckdint.h> test with the C++ compiler and if that compiles OK, do not
> generate stdckdint.h.
>
> In general we're better off if we don't second-guess a working
> implementation.
I agree that when the system has a working implementation of a .h file,
we should interfere with it to the least possible amount.
But the problem here is
1) The term "working implementation" depends on the language in effect.
It may be working C and not working in C++ — that is the case that
Collin observed with GCC 15.
Or it may be working in C++ and not working in C — that is another
case.
2) The standards may extend the expected contents of <stdckdint.h>
in the future. In that case, our current dichotomy of "generate
the file" or "not generate the file" would break down as well.
I would therefore propose a more future-proof approach: based on the same
approach as we have been taken for so many other .h files.
1) In lib/stdckdint.in.h include the system's .h file if it exists,
via include_next. (Fortunately all known compilers that have 2 copies
of stdckdint.h support include_next. The fallback with
#include "absolute file name of stdckdint.h"
will work with other compilers.)
2) Parameterize this file with 4 AC_SUBSTed variables:
- one that tells whether the C compiler has <stdckdint.h>,
- one that tells whether the <stdckdint.h> seen by the C compiler
is complete (in the sense that it provides all that the GNU
replacement would do),
- one that tells whether the C++ compiler has <stdckdint.h>,
- one that tells whether the <stdckdint.h> seen by the C++ compiler
is complete.
3) In the .m4 code, make two C compiler invocations to determine the
first two of these values and - if $CXX != no - two C++ compiler
invocations to determine the other two values.
4) Determine GL_GENERATE_STDCKDINT_H based on these 4 values.
This way, we would be prepared for changes in the standards, bugs in
specific compilers, and handle C++ independently from C (which seems
to be required in this case).
Bruno
