autoconf
[Top][All Lists]
Advanced

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

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


From: Keith MARSHALL
Subject: RFC: Does hand editing of "config.h" make sense?
Date: Fri, 27 May 2005 09:49:54 +0100

Ok...  I know RFC technically means "Request for Comments", but here I'm
abusing it to mean "Request for Clarification" :-)

On another mailing list ...
   https://sourceforge.net/mailarchive/message.php?msg_id=11882330

I saw this response to a suggestion that, IMO, config.h as generated by
an autoconf managed configure script should not be edited by hand, since
that effectively tells lies to the subsequent build tools, about the
header setup on the build host.

> The book I just got on 'autoconf' mentions that editing 'config.h' is
> one of the things that is expected.  It explains the format of the
> file which includes comments to that effect.

Since this seems rather strange advice to me, I wondered what other
autoconf users, and in particular the maintainers, thought about this.

I don't know which book the OP is referring to, but if the author is
interpreting comments such as

   /* Define to 1 if you have the <someheader.h> header file. */
   #define HAVE_SOMEHEADER_H 1

to mean "if you don't believe me, feel free to change this", and so it
is ok to hack the config.h by hand, should that template not rather say

   /* Defined to 1 if you have the <someheader.h> header file. */
   #define HAVE_SOMEHEADER_H 1

to better convey the message "this is how it is; hands off; there is no
point in trying to say otherwise", rather than suggesting it's ok to
define it yourself, if you feel like it?  Maybe the file should also
start with a stronger comment, such as

   /* config.h.  Generated by configure.  Do not edit by hand.  */
   /* config.h.in.  Generated from configure.ac by autoheader.  */

BTW, why does the "#undef HAVE_SOMEHEADER_H" in config.h.in get wrapped
in comment marks, when it is copied into config.h?  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?  Or, do some
[broken] compilers choke on "#undef AN_UNDEFINED_SYMBOL"?

Best regards,
Keith.




reply via email to

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