> I'm thinking that maybe <config.h> should be generated with a double > inclusion guard
But the general rule is that <config.h> must always be included first, no? So there shouldn't ever be a possibility of including it twice. Right, which is the case in inetutils in all places where we use <config.h>. The problem pops up when you have another header file that includes <config.h> (as the first thing) to use macros from it (for libinetutils.h it is PACKAGE_BUGREPORT and HAVE_FORK or something). It might be better to have config.h do something like this: #ifdef CONFIG_H # error "config.h included twice" #endif #define CONFIG_H Not against it, but I think that: #include <config.h> #include <argp.h> /* or some other gnulib header... */ #include <config.h> /* via some internal #include; where it is the first line */ should be valid to do. > A bit later, we do: > > #include <libinetutils.h> > > which will cause warnings like: > > ../config.h:561:1: warning "HAVE_DECL_PROGRAM_INVOCATION_NAME" redefined Sp libinetutils.h includes config.h? Then that is a problem. One possible fix is to arrange for libinetutils.h to be built from libinetutils.in.h, the same way that (for example) stdint.h is built from stdint.in.h in gnulib. Right, sorry if I wasn't clear. I would prefer not to, the fix that I might go for if we can't fix this in autoconf would be: to simply do: #ifndef HAVE_CONFIG_H #error "config.h hasn't been included; please include it" #endif But I think that autoconf should have the guard for double inclusion.