Hi Paul,
> > I see the problem now: glibc's <sys/cdefs.h> and Gnulib's <cdefs.h> have
> > the same include guard!
>
> I want the files to be identical (eventually), which is why they have
> the same include guard.
If they have the same include guard, then
1. People who use a not-yet-released glibc, if they don't want to get
errors from using Gnulib, force us to sync this file from glibc on a
daily basis.
2. We are in trouble if glibc renames some internal macros of this
file. For example, if in glibc version 2.32 you have a macro __LDBL_FOO
and in glibc 2.33 this macro is renamed to __LBDL_FOOBAR, and another
macro is introduced with the old name __LDBL_FOO, we're in trouble,
because we cannot ship a single file that works both for installed
headers of glibc 2.32 and 2.33.
3. If some distributor (Red Hat, SuSE, etc.) makes local changes to this
file in glibc (and corresponding changes in e.g. /usr/include/stdio.h),
we are in trouble as well.
> Is there some way to arrange for them to be identical?
I think we need to go the opposite way: decouple this file from what glibc
has.
Now, the art of doing that is to do it in a way that allows easy bidirectional
merges of the modules 'glob', 'fnmatch', 'regex', etc.
Bruno
