Re: Handling of #undef FOO

[Ralf Wildenhues]

Hello,

* Eric Blake wrote on Mon, Jan 07, 2008 at 03:05:45PM CET:
>
> Ralf is correct - autoconf's current approach only triggers redefinition
> problems for packages that don't follow the rules recommended by autoconf.
> ~ Any patches are welcome, but I won't be spending time writing the patch
> myself, since none of the packages I maintain break the recommended rules
> of config.h handling.

Actually, I don't think a patch that changes AC_DEFINE to output
  #ifndef FOO
  #define FOO
  #endif

should be accepted.  Rationale: it hides actual bugs, for example
installing a config.h file, or including it too late.

* Ismail Dönmez wrote on Mon, Jan 07, 2008 at 06:23:06PM CET:
> Monday 07 January 2008 09:25:10 tarihinde Ralf Corsepius şunları yazmıştı:
> > Can you provide a real world example for which this happens?
> 
> Add Python to that which installs pyconfig.h , sigh... My m4 foo is really 
> lacking, I would appreciate a pointer or RTFM to fix this.

The code to generate config headers is in
autoconf/lib/autoconf/status.m4 (gets installed to
...share/autoconf/autoconf/status.m4).  _AC_OUTPUT_HEADERS_PREPARE and
_AC_OUTPUT_HEADER are the relevant macros.  In the recent couple of
years, this code has been rewritten a few times; the next Autoconf
release will sport a rather hefty rewrite of it, to be more efficient.
It is not easy to read, unfortunately, and I would not recommend to
touch it without knowing at least sh and sed in and out.

There are ways to mangle config.h files to make their defined values
package-unique (a macro from the Autoconf Macro Archive does that, for
example), or generate headers from hand-written templates (containing
only a few package-specific variables) that can avoid all this trouble.
The packages you are having problems with really, Really should avoid
installing their generic config.h files.

Hope that helps.

Cheers,
Ralf