PACKAGE_NAME, PACKAGE_VERSION etc

[Balint Joo]

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 "address@hidden"

/* 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 "address@hidden"

/* 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: address@hidden           address@hidden
WWW  : http://www.ph.ed.ac.uk/~bj
-------------------------------------------------------------------