[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Don't #include gnulib-generated .h files from config.h
From: |
Bruno Haible |
Subject: |
Don't #include gnulib-generated .h files from config.h |
Date: |
Sun, 25 Sep 2022 01:10:23 +0200 |
With the current gnulib, I'm getting two new test failures of 'lang-c' and
'lang-c++' in GNU gettext. 'lang-c' for example fails to compile the sample
program:
FAIL: lang-c
============
prog.c
../..\config.h(3288): fatal error C1083: Cannot open include file:
'stdalign.h': No such file or directory
FAIL lang-c (exit status: 1)
The gettext sample programs include <config.h>. On this platform, there is no
<stdalign.h>, and thus stdalign.m4 has stuffed a
#include <stdalign.h>
into config.h, intending to include the gnulib-generated stdalign.h.
This is problematic for three reasons:
* Since the gnulib-generated stdalign.h is in a different directory than
config.h, the compilation command needs additional -I options. This is
likely to occur not only in GNU gettext, but also in other packages.
And adding such -I options may cause other generated .h files
(stdio.h, unistd.h, etc.) to become visible, which can activate some
rpl_ substitutes and thus cause link errors.
* There can be several gnulib-tool invocations in the scope of a single
configure.ac and config.h. It is not even clear to the package maintainer
from which gnulib build directory to take stdalign.h.
* stdalign.h is created by "make" — after config.h, which is created by
config.status. And similarly, "make clean" erases stdalign.h but not
config.h. So, for some time, we have a config.h file which includes a
nonexistent file. This too can cause all sorts of trouble that will
be difficult to track down by the package maintainer.
Thus, it's best to avoid such a situation. This holds not only for
<stdalign.h> but also for <stdbool.h>. For <assert.h> on the other hand
I think the trouble is limited, because <assert.h> always exists among the
system header files.
The attached patches do this. Note that this raises a question how to get
along with an AC_C_BOOL macro, since obviously Autoconf cannot be kept
in sync with Gnulib. Maybe AC_C_BOOL will need to take an optional argument
AC_C_BOOL([substitute for stdbool.h]) ?
2022-09-24 Bruno Haible <bruno@clisp.org>
stdbool: Don't #include a gnulib-generated stdbool.h from config.h.
* m4/c-bool.m4 (gl_C_BOOL): Check for stdbool.h and for _Bool. If
stdbool.h does not exist, don't #include <stdbool.h> but instead put the
substitute code into config.h.
2022-09-24 Bruno Haible <bruno@clisp.org>
stdalign: Don't #include a gnulib-generated stdalign.h from config.h.
* m4/stdalign.m4 (gl_STDALIGN_H): Check for stdalign.h. If it does not
exist, don't #include <stdalign.h> but instead put the substitute code
into config.h.
0001-stdalign-Don-t-include-a-gnulib-generated-stdalign.h.patch
Description: Text Data
0002-stdbool-Don-t-include-a-gnulib-generated-stdbool.h-f.patch
Description: Text Data
- Don't #include gnulib-generated .h files from config.h,
Bruno Haible <=