Re: Why conditionally include config.h?

2012-09-16 Thread 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

Re: Why conditionally include config.h?

2012-09-15 Thread Kip Warner
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

Re: Why conditionally include config.h?

2012-09-15 Thread Kip Warner
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

Re: Why conditionally include config.h?

2012-09-15 Thread Kip Warner
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

Re: Why conditionally include config.h?

2012-09-15 Thread Kip Warner
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.

Re: Why conditionally include config.h?

2012-09-15 Thread Russ Allbery
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

Why conditionally include config.h?

2012-09-13 Thread Kip Warner
Hey list, Why do many autoconfiscated projects bracket inclusion of the generated config.h with #if HAVE_CONFIG_H / #endif. Assuming the build environment was configured, why shouldn't the source just always unconditionally include config.h? I mean if it isn't there, typically that means the user

Re: Why conditionally include config.h?

2012-09-13 Thread Eric Blake
On 09/13/2012 05:22 PM, Kip Warner wrote: Hey list, Why do many autoconfiscated projects bracket inclusion of the generated config.h with #if HAVE_CONFIG_H / #endif. Bad copy-and-paste habits. Probably because historically, libtool prided itself on being usable even without autoconf, and

Re: Why conditionally include config.h?

2012-09-13 Thread Marko Lindqvist
On 14 September 2012 02:43, Eric Blake ebl...@redhat.com wrote: On 09/13/2012 05:22 PM, Kip Warner wrote: Hey list, Why do many autoconfiscated projects bracket inclusion of the generated config.h with #if HAVE_CONFIG_H / #endif. Bad copy-and-paste habits. I've seen some packages where

Re: Why conditionally include config.h?

2012-09-13 Thread Bob Friesenhahn
On Thu, 13 Sep 2012, Kip Warner wrote: Why do many autoconfiscated projects bracket inclusion of the generated config.h with #if HAVE_CONFIG_H / #endif. Assuming the build environment was configured, why shouldn't the source just always unconditionally include config.h? I mean if it isn't

Re: Why conditionally include config.h?

2012-09-13 Thread Russ Allbery
Marko Lindqvist cazf...@gmail.com writes: On 14 September 2012 02:43, Eric Blake ebl...@redhat.com wrote: On 09/13/2012 05:22 PM, Kip Warner wrote: Why do many autoconfiscated projects bracket inclusion of the generated config.h with #if HAVE_CONFIG_H / #endif. Bad copy-and-paste habits.