使用自动工具时 PACKAGE_NAME 和其他宏发生冲突
当对库和基于该库构建的软件使用自动工具(带有 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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果您的应用程序可能动态链接到库,则将库中的静态字符串静态构建到应用程序中是没有意义的。
否则,您可能需要查找
ax_prefix_config_h.m4
。我仍然会尝试避免安装 config.h 文件并定义库的 API,而不求助于 config.h:
确保公共库头文件不< 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 toconfig.h
:Make sure that the public library header files do not
#include "config.h"
, and that the library does not install itsconfig.h
.您应该能够通过在软件的
configure.ac
中调用AC_CONFIG_SUBDIRS([library])
将库指定为软件的“子包”。这应该消除冲突,并且顶级配置中的设置仍将向下传播到子包。以下是描述此功能的 Autoconf 手册页面的链接: http ://www.gnu.org/software/hello/manual/automake/Subpackages.html
You should be able to designate the library as a "subpackage" of the software by calling
AC_CONFIG_SUBDIRS([library])
in the software'sconfigure.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