使用自动工具时 PACKAGE_NAME 和其他宏发生冲突

发布于 2024-08-27 18:37:13 字数 1160 浏览 13 评论 0原文

当对库和基于该库构建的软件使用自动工具（带有 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 等？

编辑：尝试更好地解释。

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

原文

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.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦里兽 2024-09-03 18:37:13

如果您的应用程序可能动态链接到库，则将库中的静态字符串静态构建到应用程序中是没有意义的。

否则，您可能需要查找 ax_prefix_config_h.m4。

我仍然会尝试避免安装 config.h 文件并定义库的 API，而不求助于 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;
}

确保公共库头文件不< code>#include "config.h"，并且该库不会安装其 config.h。

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.

回复收藏 0 原文