[Top][All Lists]
[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.
- config.h inclusion, Ralf Wildenhues, 2005/09/13
- Re: config.h inclusion, Ralf Wildenhues, 2005/09/13
- Re: config.h inclusion, Paul Eggert, 2005/09/13
- Re: config.h inclusion, Ralf Wildenhues, 2005/09/14
- Re: config.h inclusion, Paul Eggert, 2005/09/15
- Re: config.h inclusion, Ralf Wildenhues, 2005/09/16
- Re: config.h inclusion, Paul Eggert, 2005/09/19
- Re: config.h inclusion, Ralf Wildenhues, 2005/09/21
- Re: [bug-gnulib] Re: config.h inclusion, Bruno Haible, 2005/09/14
- Re: config.h inclusion, Paul Eggert, 2005/09/14