[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: Does hand editing of "config.h" make sense?
From: |
Stepan Kasal |
Subject: |
Re: RFC: Does hand editing of "config.h" make sense? |
Date: |
Fri, 27 May 2005 14:43:29 +0200 |
User-agent: |
Mutt/1.4.1i |
Hi,
On Fri, May 27, 2005 at 12:15:33PM +0100, Keith MARSHALL wrote:
> > But if you port to a new or very weird platform, you can have problems
> > running configure there. Then it comes handy that you take the
> > template and fill in the info, or correct the mistakes in config.h.
actually, I was slightly wrong. In this situation you fill in config.h.in,
you don't edit config.h.
> [...], after a *successful* run of configure had left HAVE_TERMIOS_H
> undefined. Another list subscriber had suggested that it he *needed* to
> edit config.h to fix this, because he did have termios.h, and configure
> got it wrong. [...]
Well, if configure really got something wrong, it makes sense to edit
config.h, fix the mistake. I just don't think this happens every year.
And if it is so exceptional, I think it shouldn't be adviced in manual,
and it wasn't a good advice on the list. "Show me config.log" would be
much better answer.
Actually, when I think about it, there is also the oposite situation:
you don't want to use foo, yet ./configure detects it.
If there is no --disable-foo, and you cannot edit configure.ac (perhaps
you don't have the exect version which the maintainer used to cook his
version), you can edit config.h to #undef HAVE_FOO.
That has better chance to succeed.
And you asked:
> BTW, why does the "#undef HAVE_SOMEHEADER_H" in config.h.in get wrapped
> in comment marks, when it is copied into config.h?
The following comment is part of every ./configure script (it originates
in /usr/share/autoconf/autoconf/status.m4):
# This sed command replaces #undef with comments. This is necessary, for
# example, in the case of _POSIX_SOURCE, which is predefined and required
# on some systems where configure will not decide to define it.
So this is kind of hack, but it would be too risky to try to change it
now.
> Or, do some [broken] compilers choke on "#undef AN_UNDEFINED_SYMBOL"?
So your guess wasn't right.
> Does it not make more sense to forcibly ensure that HAVE_SOMEHEADER_H is
> not defined, if configure has determined that someheader.h isn't present?
You say ``forcibly.'' I don't think you have to use force here.
config.h is usually included as the very first include, so there is no
place where the symbol should be predefined.
Have a nice day,
Stepan Kasal