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  as
>   the first non-comment line in the file.
> 
> * Internal (non-installed) header files #include  (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  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 .  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


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?

2012-09-15 Thread Russ Allbery 
Kip Warner  writes:

> Thanks Russ. That was very helpful. Is there a general rule on which
> source files to #include , 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  as
  the first non-comment line in the file.

* Internal (non-installed) header files #include  (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  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 .  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) 

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

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.  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 , 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?

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 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?

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 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?

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
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?

2012-09-13 Thread Russ Allbery 
Marko Lindqvist  writes:
> On 14 September 2012 02:43, Eric Blake  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.

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

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.

-- 
Russ Allbery (r...@stanford.edu) 

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

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 there, typically
that means the user didn't configure first which ought to be an error
anyways, no?


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.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: Why conditionally include config.h?

2012-09-13 Thread Marko Lindqvist 
On 14 September 2012 02:43, Eric Blake  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 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.


 - ML

___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

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 therefore
libtool headers have to use HAVE_CONFIG_H.  Projects that use libtool
would then copy libtool's habits, even when they use autoconf, and the
practice has spread to projects that don't even use libtool.

> 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 didn't configure first which ought to be an error
> anyways, no?

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.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

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 didn't configure first which ought to be an error
anyways, no?

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