Re: config.h inclusion

[Ralf Wildenhues]

Hi Paul, Simon, Bruno,

* Paul Eggert wrote on Thu, Sep 15, 2005 at 01:10:53AM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> > 1) Fix the files that forgot to guard inclusion by HAVE_CONFIG_H.
> >    This is the first patch.
> 
> Actually, I was thinking that we should go the other way, and include
> config.h unconditionally (except for glibc-derived code).  As far as I
> know, nobody outside of glibc uses this code without also defining
> HAVE_CONFIG_H.  In the meantime let's leave this alone.

I don't understand this.  If we were to include it conditionally, it
would not break _anything_, not even future users that happen not to use
config.h.  gnulib is also intended for new use (in `situations not
anticipated before'), right?

Unconditionally, you force users to use config.h.  Maybe you should also
force use of AC_CONFIG_HEADERS, similar to how libltdl tries to do it?
(I really think this is a bad idea in general, don't go this way,
please.)

I learned about this issue while actually trying to make use of a module
with one of the unguarded files; I did not use AC_CONFIG_HEADERS.

> Also, now that I think about it I prefer "#if HAVE_CONFIG_H" to
> "#ifdef HAVE_CONFIG_H".  (I don't know about other people.)  But if we
> remove the #if for non-glibc code, we might as well stick to the glibc
> convention for the glibc code.

FWIW, I don't have a strong opinion on this issue, but I remember a
discussion that led to the contrary conclusion a while ago on one of the
GNU lists.  Can't find it now, but found a couple of data points
nonetheless:
- #if HAVE_CONFIG_H  breaks with the Metrowerks CodeWarrior compiler:
  http://ghostscript.com/pipermail/gs-code-review/2004-December/004721.html
- GCS (`Conditional Compilation') suggests always defining symbols to
  values, but autoconf does not honor it in the case of HAVE_CONFIG_H.
- `gcc -Wundef' generates a diagnostic:
  http://lists.gnu.org/archive/html/bison-patches/2001-12/msg00000.html

Surely there are also reasons for `#if'.

> > -#if HAVE_CONFIG_H
> > -# include <config.h>
> > -#endif
> > +/* You must include config.h before including this file. */
> 
> Let's omit the comment.  That's understood, in all gnulib source code.
> (We can remove any instances of the comment that are already there.)

Fine with me.

* Simon Josefsson wrote on Wed, Sep 14, 2005 at 10:48:28PM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> >    I have added a warning to the headers that config.h needs to be
> >    included beforehand.
> 
> Do we really need this comment?  It is better to document this in
> doc/gnulib.texi, in my opinion.  Then it will cover all files, not
> only the one where we remember to add the comment to.

ACK, see above.

I'll be happy to produce a new set of patches, after reaching consensus.

* Bruno Haible wrote on Wed, Sep 14, 2005 at 10:48:32PM CEST:
> Ralf Wildenhues wrote:
> > Thinking out loud, `#if HAVE*' vs. `#ifdef HAVE*' also could be
> > uniformized for other values of `*' .. not sure it's worth the effort.
> 
> If we were to do this, then towards #if, not towards #ifdef.
> 
> $ grep '# *if HAVE_' *.h *.c | wc -l
>     429
> $ grep '# *ifdef HAVE_' *.h *.c | wc -l
>     197
> 
> The reason is that some *.m4 files need to define HAVE_FOOBAR to 0 when foobar
> is absent; this is useful for using HAVE_FOOBAR as a C expression. But
> we don't want to have to think about the difference between "#if HAVE_" and
> "#ifdef HAVE_". So the choice is to canonicalize on "#if HAVE_".

It may not be useful after all to canonicalize every macro
(!=HAVE_CONFIG_H), for reasons stated above.

Cheers,
Ralf