How to avoid redefining VERSION, PACKAGE, etc

Question

I haven't seen any questions relating to GNU autoconf/automake builds, but I'm hoping at least some of you out there are familiar with it. Here goes:

I have a project (I'll call it myproject) that includes another project (vendor). The vendor project is a standalone project maintained by someone else. Including a project like this is fairly straightforward, but in this case there is a tiny snag: each project generates its own config.h file, each of which defines standard macros such as PACKAGE, VERSION, etc. This means that, during the build, when vendor is being built, I get lots of errors like this:

... warning: "VERSION" redefined
... warning: this is the location of the previous definition
... warning: "PACKAGE" redefined
... warning: this is the location of the previous definition

These are just warnings, for the time being at least, but I would like to get rid of them. The only relevant information I've been able to turn up with a Google search is this thread on the automake mailing list, which isn't a whole lot of help. Does anybody else have any better ideas?

Answer 1

Some notes:

• you didn't mention how config.h was included - with quotes or angle brackets. See this other question for more information on the difference. In short, config.h is typically included with quotes, not angle brackets, and this should make the preprocessor prefer the config.h from the project's own directory (which is usually what you want)
• You say that a subproject should be including the enclosing project's config.h Normally this is not at all what you want. The subproject is standalone, and its PACKAGE and VERSION should be the one of that subproject, not yours. If you include libxml in your xmlreader project for example, you would still want the libxml code to be compiled with PACKAGE libxml and VERSION (whatever the libxml version is).
• It is usually a big mistake to have config.h be included from public headers. config.h is always private to your project or the subproject, and should only be included from .c files. So, if your vendor's documentation says to include their "vendor.h" and that public header includes config.h somehow, then that is a no-no. Similarly, if your project is a library, don't include config.h anywhere from your publically installed headers.

Answer 2

It's definitely a hack, but I post-process the autogen'd config.h file:

sed -e 's/.*PACKAGE_.*//' < config.h > config.h.sed && mv config.h.sed config.h

This is tolerable in our build environment but I'd be interested in a cleaner way.

Answer 3

It turns out there was a very simple solution in my case. The vendor project gathers several header files into one monolithic header file, which is then #included by the vendor sources. But the make rule that builds the monolithic header accidentally included the generated config.h. The presence of the PACKAGE, VERSION, etc. config variables in the monolithic header is what was causing the redefinition warnings. It turns out that the vendor's config.h was irrelevant, because "config.h" always resolved to $(top_builddir)/config.h.

I believe this is the way it's supposed to work. By default a subproject should be including the enclosing project's config.h instead of its own, unless the subproject explicitly includes its own, or manipulates the INCLUDE path so that its own directory comes before $(top_builddir), or otherwise manipulates the header files as in my case.