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
