Dear Autoconf-ers, I am involved in developing a project with GNU autotools. We use several libraries together, all of which are "layered" on top of each other, and each are individually configured with autoconf.
We have recently found that using AC_CONFIG_HEADERS([config.h]) pollutes our config.h file with package related #defines:
/* Name of package */ #define PACKAGE "qdp"
/* Define to the address where bug reports for this package should be sent. */ #define PACKAGE_BUGREPORT "bj@xxxxxxxxxxx"
/* Define to the full name of this package. */ #define PACKAGE_NAME "qdp"
/* Define to the full name and version of this package. */ #define PACKAGE_STRING "qdp 1.7"
etc. These are certainly not in our config.h.in and seem to be generated by autoheader (?) which gets called when we invoke autoconf.
The trouble is that when we configure two packages, the #define macro names conflict. Ie we configure build and install package 1 and its config.h contains the above.
We then configure package 2 which uses the config.h from package 1. But package 2 also contains the #define macros
/* Name of package */ #define PACKAGE "chroma"
/* Define to the address where bug reports for this package should be sent. */ #define PACKAGE_BUGREPORT "bj@xxxxxxxxxxx"
/* Define to the full name of this package. */ #define PACKAGE_NAME "chroma"
/* Define to the full name and version of this package. */ #define PACKAGE_STRING "chroma 1.7"
and as a result we get many compiler warnings about macro PACKAGE being redefined, PACKAGE_BUGREPORT being redefined etc.
While this doesn't interfere with the build does annoy to a great extent. We put a lot of effort into using the autotools and have as a result got a great deal of flexibility with the build system and have successfully built our code on machines ranging from workstations to machines were we need to cross compile. We are really pleased with our effort but this issue is a real thorn in our side.
We can probably hack around it by explicitly #undef ing all the unwanted macros, directly after including the config.h but this is an ugly cludge. Is there any way to stop autoconf messing with our config.h.in and config.h in this way? There must be. Surely there are many people developing multiple layers of libraries with autoconf.
Please let us know if you can help. This behaviour is becoming annoying, and causes much repetition of effort in putting #undefs into files post configuration. At the least we should somehow manage to put a pre/post fix
on the macros so that they don't conflict.
With best wishes, Balint -- ------------------------------------------------------------------- Dr Balint Joo Post Doctoral Research Fellow School of Physics University of Edinburgh Mayfield Road, Edinburgh EH9 3JZ Scotland UK Tel: 0131 650 6469 (from UK) +44-131-650-6469 (from outwith UK) Fax: 0131 650 5902 (from UK) +44-131-650-5902 (from outwith UK) email: bj@xxxxxxxxxxx bj@xxxxxxxxxxxxxxxxx WWW : http://www.ph.ed.ac.uk/~bj -------------------------------------------------------------------