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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
