我最近遇到了一个库，它在公共头文件中使用HAVE_FEATUREFOO等变量。
它还包括声明#include "config.h"。这些声明也用于结构声明，并有条件地删除struct成员。用于库构建的值的不一致性以及依赖程序的构建将导致内存损坏。
因此，使用库及其标题可能会产生以下后果：
#include "config.h"失败了，我对autotools很新，但经过一些研究后我发现，它们是用AC_DEFINE or AC_DEFINE_UNQUOTED定义的。而且，config.h是使用AC_CONFIG_HEADERS生成的。
经过进一步的研究，我找到了include_HEADERS，它安装了标题。并且，如果将config.h添加到列表中，则会正确安装它。
这是正确的方法，安装config.h由autotools生成的AC_CONFIG_HEADERS头文件？
用户代码永远不应包含生成的config.h文件。这意味着您的库头应该独立于配置测试，您不应该安装config.h。
是否正确的方法，安装由AC_CONFIG_HEADERS由autotools生成的config.h头文件？
如果属于项目的其他已安装标头依赖于config.h，那么是的，也必须安装config.h。这是唯一可行的方法，因为构建的软件依赖于config.h中记录的构建时构建系统属性。一般来说，你不能指望在事后正确地再创造它。
但是安装的标题首先不应该是#include的Autotools config.h标题，也不应该间接依赖它。那么，也不应该在包含文件搜索路径中安装名为config.h的文件，或者在有时可能被添加到包含路径中的任何目录中安装。冲突的风险太大 - 在某种程度上标题名称，但更重要的是这些标题定义和依赖的宏名称。
底线：Autotools config.h文件用于构建与之关联的项目，而不是用于构建结果。特别是，当这样的项目是或包括库时，config.h不适合库自己的头文件的任何使用方式，或者不希望使用库调用的代码直接使用。 Autotools提供了不同的机制，通过自定义用于安装的标头，可以记住构建时系统配置。
那么你对于你所询问的图书馆有什么看法呢？我认为您描述的问题表明代码质量很差，因此您应该强烈考虑寻找替代方案。您可以尝试修复该项目，但它不太值得您花时间，特别是作为Autotools新手。