Conflicting PACKAGE_NAME and other macros when using autotools.

Question

When using autotools (with a config.h file) for both a library, and a software built on that library, the compiler complains about a redefinition of some macros (PACKAGE_NAME, PACKAGE_TARNAME and so on).

How can I prevent this?

The config.h file is needed in the library to propagate it's setting to the software that use it.

Right now I have a wrapper script library_config.h that includes the original config.h and provides defaults when the user is not using autotools, but even undefining the macros in that package I get the redefinition warning from gcc.

#ifndef LIB_CONFIG_H
#define LIB_CONFIG_H
#ifdef HAVE_CONFIG_H
#  include "config.h"
#  undef PACKAGE
#  undef PACKAGE_BUGREPORT
#  undef PACKAGE_NAME
#  undef PACKAGE_STRING
#  undef PACKAGE_TARNAME
#  undef PACKAGE_VERSION
#  undef VERSION
#else
#  if defined (WIN32)
#    define HAVE_UNORDERED_MAP 1
#    define TR1_MIXED_NAMESPACE 1
#  elif defined (__GXX_EXPERIMENTAL_CXX0X__)
#    define HAVE_UNORDERED_MAP 1
#  else
#    define HAVE_TR1_UNORDERED_MAP 1
#  endif
#endif
#endif

I believe the best option would be to have a library without that macros: How can I avoid the definition of PACKAGE, PACKAGE_NAME and so on in the library when using autotools?

EDIT: attemp to explain better.

When using the AC_CONFIG_HEADER macro in the configure.ac of the library I produce a config.h file with a lot of useful defines. This defines are useful for the library itself (both for it's compiled part and for its header files) AND for the client software. It's a pity however that the AC_CONFIG_HEADER mixes the useful macros that I need with other generic defines with fixed names (PACKAGE, PACKAGE_NAME) that clash when autotools are used also for the client software configuration.

Answer 1

If your application might dynamically link to the library, it makes no sense to have the static strings from the library statically built into the application.

Otherwise, you might want to look for ax_prefix_config_h.m4.

I would still just try to avoid installing a config.h file and define the library's API without resorting to config.h:

/* library.h */
const char library_version[];

/* library.c */
#include "library.h"
#include "config.h" /* the library's config.h */
const char library_version[] = PACKAGE_VERSION;

/* application.c */
#include "library.h"
#include "config.h" /* the application's config.h */
int main()
{
   print("This is app version %s.\n", PACKAGE_VERSION);
   print("The library is version %s\n", library_version);
   return 0;
}

Make sure that the public library header files do not #include "config.h", and that the library does not install its config.h.

Answer 2

You should be able to designate the library as a "subpackage" of the software by calling AC_CONFIG_SUBDIRS([library]) in the software's configure.ac. That should eliminate the conflicts, and the settings from the top-level configure will still propagate down to the subpackage.

Here is the link to the page of the Autoconf manual describing this feature: http://www.gnu.org/software/hello/manual/automake/Subpackages.html

Answer 3

How do you deal with PACKAGE_* macro conflicts when the library you are distributing consists of C++ template code that must include the generated config.h macros to utilize machine specific configuration information? The conflict will occur when a user of the library compiles your distributed template code and the client code uses a generated autoheader generated file.

Do I need to manually remove the conflicting macro definitions from the generated header before distribution?