Re: Why conditionally include config.h?
On Thu, 2012-09-13 at 17:43 -0600, Eric Blake wrote: Yep, you are exactly right, which is why gnulib doesn't use HAVE_CONFIG_H, and even provides a syntax check rule that you can copy into your project to also avoid it yourself. Thanks Eric. That was very helpful. I see that you also made some contributions to Gnulib. Can you point me to more information on this syntax check rule? I'd like to learn more. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why conditionally include config.h?
On Fri, 2012-09-14 at 02:58 +0300, Marko Lindqvist wrote: I've seen some packages where same sources are used with multiple build systems (typically autotools in more unixy systems and visual studio project files on Windows) and it's actually needed to weed out config.h include when building with system that does not provide it. But more often #ifdef HAVE_CONFIG_H is just idiom copied from some other project. For example, in our freeciv project, this would need cleanup. It used to be possible to build without autotools and fc_config.h (for systems lacking autotools support those ancient times), and thus #ifdefs are used. However, if one would try to build without HAVE_CONFIG_H defined today, it would go horribly wrong. Thanks Marco. Very helpful. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why conditionally include config.h?
On Thu, 2012-09-13 at 19:14 -0500, Bob Friesenhahn wrote: Since subsequent responses are not yet adequate ... It is not necessary to have a configuration header when Autoconf is used. If a configuration header is not used, then all definitions appear on the compiler command line and HAVE_CONFIG_H is not defined. However, it is a bug for #if HAVE_CONFIG_H to be used in any installed header file because it might apply to any package, including some other package. Right. That makes sense. Thanks for your help Bob. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why conditionally include config.h?
On Thu, 2012-09-13 at 17:17 -0700, Russ Allbery wrote: I believe the #ifdef wrapper used to be recommended by the Autoconf manual way back, many moons ago (2.13 days at the latest), because it was how the transition from defining things via -D on the command line to using a header was handled. It goes along with the definition of @DEFS@, which previously (and by previously I mean a long time ago) used to contain all the results of configure as -D flags to the compiler, but which was replaced by just -DHAVE_CONFIG_H if you used the AC_CONFIG_HEADERS (or its earlier versions) macro. So, in other words, you could transition your package that was assuming -D flags on the compiler command line to using a config.h header by adding that #ifdef code to the source files, and then it would work with either Autoconf method: either a config.h file or direct -D flags on the compiler command line. I suspect the above is what's happening when you see this in really old projects, and in newer projects it's copy and paste from older projects. 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. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why conditionally include config.h?
Kip Warner k...@thevertigo.com 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 (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
