PACKAGE_FOO macros

[Jeff Squyres]

Looking through the message archives on this list, I see that there has
been discussion about the PACKAGE_FOO macros that are auto-generated by
AC_INIT.  It does not appear that there is any way that this behavior can
be "turned off".

The problem: if package A uses autoconf and generates a-config.h, and
package B also uses autoconf and generates b-config.h, #including both
a-config.h and b-config.h will generate preprocessor errors ("PACKAGE_FOO
is already defined", etc.).

I would strongly appeal to the autoconf maintainers to make it possible
for users to not have these macros generated.  The Automake maintainers
have made this possible for their PACKAGE_FOO macros -- the "no-define"
option.  Can something analogous be added to autoconf?

Previous posts on this list seem to be of one of two flavors:

1. generated .h files should always be private
2. use ac-archive/AC_CREATE_PREFIX_CONFIG_H

1. is not always true -- consider the case of using autoconf to create
libraries.  My group, for example, has packages that create libraries
containing top-level .h files that are #included by users.  These .h files
frequently have to have some kind of results from configure -- such as
type settings in function prototypes.  This is *not* private data, and
*needs* to be shared with the user.

I don't want to do #2 because that adds a prefix to *every* #define in my
.h file -- this seems like using a sledgehammer to fix a very minor
problem.  Plus, all my #define's are already properly prefixed... except
for these PACKAGE_FOO macros.

More specifically -- having *every* autoconf-generated config.h file
generate macros by the same name violates the spirit of "separate
namespaces" in macros.  Since there's only a global namespace for
preprocessor macros, the only way to segregate them is by different
prefixes.  But autoconf isn't even giving the user the option to do that
-- these macros will be named PACKAGE_FOO, regardless of what the user
wants.

Please please please give us a way to turn off (or put a prefix in front
of) these macros.

Thanks.

{+} Jeff Squyres
{+} address@hidden
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/