Re: FYI: 28-gary-sanitise-header-includes

Eric Blake <ebb9 <at> byu.net> writes:

Hi Gary,

> > 
> >> I am currently playing with a patch that follows gnulib policy of
> >> removing
> >> <config.h> from all .h, and making sure that it is the first line of
> >> all .c;
> >> hopefully that will clean up the problem.  Everything else may be
> >> factor-able
> >> into system_.h, but <config.h> must be handled specially if m4 source
> >> code is
> >> to see a consistent state.
> >
> > Include <config.h> first in all C files, and not in headers.
> 
> Add a note to HACKING to remind us (and future contributors) of this? 

Done as follows (no changelog, since HACKING is not distributed):

Index: HACKING
===================================================================
RCS file: /sources/m4/m4/HACKING,v
retrieving revision 1.9
diff -u -r1.9 HACKING
--- HACKING	1 Dec 2006 16:38:32 -0000	1.9
+++ HACKING	10 Apr 2007 14:33:14 -0000
@@ -38,6 +38,14 @@
   environment or the -G option was passed on the command line):
     http://www.opengroup.org/onlinepubs/009695399/utilities/m4.html
 
+* Except for third-party files (libtool, gnulib, ...), all .c files
+  should #include <config.h> before anything else (since there are some
+  #defines in config.h that potentially impact system headers, such as
+  when the user does ./configure --disable-assert).  This means that no
+  .h files need to #include <config.h>.  However, users compiling
+  external modules should be able to compile without <config.h>, since
+  <config.h> is specific to the M4 build and is not installable.
+
 
 3. Bootstrapping
 ================


> > Fixes regression for --disable-assert builds from 2007-04-02.
> 
> Add a test that does a VPATH --disable-assert configure and make to
> prevent a similar regression with future patches?

That would probably go best as a distcheck.  I'm debating about adding

DISTCHECK_CONFIGURE_FLAGS = --disable-assert

to Makefile.am, but did not do so on my current commit.

-- 
Eric Blake