bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: config.h inclusion


From: Noah Misch
Subject: Re: config.h inclusion
Date: Thu, 15 Sep 2005 13:40:30 -0700
User-agent: Mutt/1.5.6i

On Thu, Sep 15, 2005 at 09:45:20AM +0200, Ralf Wildenhues wrote:
> * Ralf Wildenhues wrote on Thu, Sep 15, 2005 at 08:20:28AM CEST:
> > * Paul Eggert wrote on Thu, Sep 15, 2005 at 01:10:53AM CEST:
> > 
> > > 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

>From this evidence, I would vote for standardizing on `#ifdef HAVE_CONFIG_H
... #endif' specifically.  That pleases Metrowerks and -Wundef and works with
the existing arrangement for defining HAVE_CONFIG_H.  There is no value in
supporting `if(HAVE_CONFIG_H) { ... }' specifically.

I would also vote to standardize on `#ifdef ... #endif' generally, but for a
different reason.  Autoconf macros typically either define a HAVE_ symbol to 1
or leave it undefined.  Changing them to define to zero instead would break
every program that currently tests the macro with #ifdef.  We must not do that,
so #ifdef is the remaining standards-conforming and -Wundef-pleasing solution.

For whatever reason, `if(HAVE_FOO) { ... }' is relatively unpopular.  If an
author does wish to use it and package-specific configuration code sets
HAVE_FOO, he or she ought to feel free to define HAVE_FOO to 1/0 rather than the
conventional 1/undefined.  If a standard macro sets HAVE_FOO, the programmer
would add this to his or her sources:

  #ifndef HAVE_FOO
  # define HAVE_FOO 0
  #endif

That fragment should appear in the translation unit after all includes, such
that HAVE_FOO now taking on a false definition does not confuse header files
that assume conventional HAVE_* semantics.

> Another issue:  Packages using libltdl from libtool CVS will break with
> `#if HAVE_CONFIG_H', because libltdl macros cause HAVE_CONFIG_H to be
> defined as `<config.h>' or similar.  One or the other needs to be fixed.
> Comments?

Please pass the name of the configuration header in a separate define.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]