2

当对库和基于该库构建的软件使用自动工具（带有config.h文件）时，编译器会抱怨重新定义了某些宏（PACKAGE_NAME、PACKAGE_TARNAME 等）。

我怎样才能防止这种情况？

库中需要该config.h文件以将其设置传播到使用它的软件。

现在我有一个library_config.h包含原始文件的包装脚本，config.h并在用户不使用自动工具时提供默认值，但即使取消定义该包中的宏，我也会收到来自 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

我相信最好的选择是拥有一个没有该宏的库：使用自动工具时，如何避免在库中定义 PACKAGE、PACKAGE_NAME 等？

编辑：尝试更好地解释。

在库中使用AC_CONFIG_HEADER宏时，configure.ac我会生成一个config.h包含许多有用定义的文件。这个定义对于库本身（对于它的编译部分和它的头文件）和客户端软件都很有用。然而遗憾的是，AC_CONFIG_HEADER将我需要的有用宏与其他具有固定名称（PACKAGE、PACKAGE_NAME）的通用定义混合在一起，当自动工具也用于客户端软件配置时会发生冲突。

4

2 回答 2

2

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.

于 2010-04-03T17:12:59.170 回答
1

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

于 2010-04-03T20:46:36.053 回答