Kip Warner <kip@xxxxxxxxxxxxxx> 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 (rra@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/> _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
