[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PACKAGE_FOO macros
From: |
Jeff Squyres |
Subject: |
PACKAGE_FOO macros |
Date: |
Thu, 24 Oct 2002 18:18:38 -0400 (EDT) |
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/
- PACKAGE_FOO macros,
Jeff Squyres <=