Re: reasons for having no inclusion guards in config.h

[John Calcote]

On 3/7/2010 4:38 PM, Carsten Heinrici wrote:
> > > but: if there is this golden rule to always have them included first,
> > > there should be no harm if they would include inclusion guards.
> > >
> > > what am I missing here?
> > >        
> > There may be several config.h files, each of which has somewhat different
> > content.  Bing!
> >      
> How do you include several config.h files?
> In general, a C file starts with
>
> #if defined(HAVE_CONFIG_H)
> #  include "config.h"
> #endif
>
> This would never include more than one, I think.
>    

Ultimately, I think folks who include config.h in more than one of their 
own header files (non-public ones, hopefully) are worried that config.h 
may be included more than once by their own source files that include 
more than one of these internal headers. They could solve this potential 
problem like this:

internal.h:
----------
#ifndef INTERNAL_H_INCLUDED
#define INTERNAL_H_INCLUDED

#ifdef HAVE_CONFIG_H
#  ifndef CONFIG_H_INCLUDED
#    include "config.h"
#    define CONFIG_H_INCLUDED
#  endif
#endif

...

#endif    /* INTERNAL_H_INCLUDED */
----------

But that's more painful than they want. Why should they have to define 
an include guard for config.h? They don't do it for others? What it 
comes down to is this: It's a difficult problem to generate a unique 
include guard for config.h.

John