Re: Why conditionally include config.h?

[Kip Warner]

On Sat, 2012-09-15 at 17:45 -0700, Russ Allbery wrote:
> I wouldn't go so far as to say that this is a general rule for everyone
> using Autoconf, but the way that I do it, which I believe is fairly
> common, is:
> 
> * All regular source files (*.c files, for example) #include <config.h> as
>   the first non-comment line in the file.
> 
> * Internal (non-installed) header files #include <config.h> (generally
>   after the multiple-inclusion header guard) if and only if they use
>   Autoconf results directly.  I do not do this if the header file just
>   uses data types that Autoconf may rename, only if the header file uses
>   the regular HAVE_* symbols and the like.
> 
>   I do this only because I'm kind of obsessive about header files being
>   self-contained and hence including everything they use.  Since every
>   source file has #include <config.h> before anything else, including
>   internal headers, there's really no need to include config.h in internal
>   header files.  You may not want to follow my example here.  :)
> 
> * Public, installed header files never #include <config.h>.  In general, I
>   try to write all public interfaces so that they don't rely on anything
>   outside of C89 or C99 (whatever I'm targetting) and therefore do not
>   need any conditional results.
> 
>   Sometimes this isn't possible; when it isn't, I generate a separate
>   publicly-installed header file that contains the definitions that I need
>   but renamed so that they're within the namespace of my project (adding
>   FOOBAR_ in front of all the HAVE_ symbols, for example).  I usually just
>   roll this myself, but there are various macros to do this in, for
>   example, the Autoconf Archive if you have this problem.  I then include
>   that header file in other publicly-installed header files.
> 
> Packages that violate the latter principal are extremely annoying.  Note
> that, because of the various PACKAGE_* defines, any Autoconf-generated
> config.h is basically guaranteed to always conflict with any config.h from
> another package, so this isn't something you can ever get away with.
> 
> For example, when developing Apache modules, I have to generate a
> separate, stripped mod-config.h file in Autoconf to use with the module
> source files, since they have to include Apache header files as well and
> the Apache header files include an Autoconf-generated config.h file with
> no namespacing.  This is all very awkward and annoying, so please don't do
> that.  :)  (Other common culprits for this are the headers generated by
> scripting languages for their dynamically-loaded extension mechanism.)

Hey Russ. I just wanted to say thank you for helping to create some good
habits as I become more experienced with the autotools. The advice you
gave makes sense, although, today at least, I haven't any need for
public system headers (yet). But should I ever have a need for creating
them, I'll be sure to pay heed to your advice.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com

signature.asc
Description: This is a digitally signed message part