使用自动工具正确安装共享库的 config.h

Correct installation of config.h for shared library using autotools

本文关键字：共享 config 安装 工具      更新时间：2023-10-16

我正在转换一个使用autotools构建系统的C++程序来使用共享库，并引入了libtool的使用。大部分程序功能都放在共享库中，由主程序加载，以便将来其他程序可以访问公共代码。

在整个程序和库源代码中，生成的自动标头config.h与通常的宏一起使用：

#if HAVE_CONFIG_H
# include <config.h>
#endif

configure.ac 我使用宏来生成它：

AC_CONFIG_HEADERS([config.h])

我的问题是，我是否需要安装config.h才能让其他人能够使用我的库，如果是这样，适当的方法是什么，是否应该重命名以避免冲突等？

我找到的关于此的最多信息在这里：

http://www.openismus.com/documents/linux/building_libraries/building_libraries#installingheaders

但这几乎不是官方来源。

永远不要安装自动标题的config.h。

库的用户最不需要的就是来自宏的干扰 从您的config.h中泄漏出来 .您的库可能有HAVE_FOOBAR，但我的软件可能以禁用 foobar 的方式编译，因此HAVE_FOOBAR会破坏我的编译。

存档中的AX_PREFIX_CONFIG宏是一种解决方法，其中所有内容都带有前缀。

更好的方法是创建一个模板文件（例如 blargconfig.h.in ） 的行如下：

typedef @BLARG_TYPE@ blarg_int_t;
@BLARG_RANDOM_INCLUDE@

然后在configure.ac中AC_SUBST()这些变量：

AC_SUBST(BLARG_TYPE, ["unsigned short"])
AC_SUBST(BLARG_RANDOM_INCLUDE, ["#include <somerandomheader.h>"])

然后将其列为输出文件：

AC_CONFIG_FILES([Makefile
                 src/Makefile
                 ...
                 include/blargconfig.h])

.h文件应与nodist_include_HEADERS一起列出;.h.in文件将自动分发，因为它列在AC_CONFIG_FILES中。

此类文件的目的地通常$libdir/packagename/include。例如，请参阅 GLib，尽管它们在没有模板的情况下生成glibconfig.h（通过在 configure.ac 中内联编写整个创建代码，正如自动本所建议的那样）。我发现这种方法不如使用AC_SUBST可维护，但它更灵活。

当然，为了帮助编译器找到依赖于平台的标头，您可能还需要编写一个 pkgconfig 脚本，就像 GLib 所做的那样。

如果

它影响接口，则需要安装config.h。实际上，如果标头需要#define，而不仅仅是.cc实现/编译单元。

如果config.h是一个问题，您可以在AC_CONFIG_HEADERS宏中指定另一个名称，例如，AC_CONFIG_HEADERS([foo_config.h]) .

安装标头的最简单方法（假设自动制作）是：

nodist_include_HEADERS = foo_config.h

在顶级Makefile.am 中。 nodist前缀告诉自动生成foo_config.h，而不是随包一起分发。

如果不使用自动制作，请在 $includedir 中安装 foo_config.h。 对于生成的标头，$exec_prefix/include可以说是一个更正确的位置，但实际上前一个位置很好。

我避免使用 config.h ，方法是在 CPPFLAGS 或 foo_CPPFLAGS 中传递相关定义，以及AC_SUBST以Makefile.am源代码构建，或AC_SUBST foo.h.in以在配置时生成标头。很多config.h是测试产生的噪声。它需要更多的基础设施，但这是我更喜欢的。除非您对自动工具感到满意，否则我不推荐这种方法。

相关文章：