Re: RFC: Does hand editing of "config.h" make sense?

[Stepan Kasal]

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