Re: Why conditionally include config.h?

[Russ Allbery]

Kip Warner <address@hidden> writes:

> Thanks Russ. That was very helpful. Is there a general rule on which
> source files to #include <config.h>, or is it as simple as any files
> that needs now or may need in the future the information contained in
> it. One exception as previously pointed out would be of course to never
> #include it in non-local / public headers.

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.)

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>