我还没有看到任何有关GNU autoconf / automake构建的问题，但是我希望至少你们中的一些人对此很熟悉。开始：

我有一个项目(我将其称为myproject)，其中包括另一个项目(供应商)。供应商项目是由其他人维护的独立项目。包含这样的项目非常简单，但是在这种情况下，存在一个小障碍：每个项目都会生成自己的config.h文件，每个文件都定义标准宏，例如PACKAGE，VERSION等。构建时，在构建供应商时，我会收到很多这样的错误：

... warning: "VERSION" redefined
... warning: this is the location of the previous definition
... warning: "PACKAGE" redefined
... warning: this is the location of the previous definition

这些只是警告，至少暂时是这样，但是我想摆脱它们。我能够通过Google搜索获得的唯一相关信息是自动制作邮件列表中的该线程，它并不是很多帮助。还有其他人有更好的主意吗？

解决方案

回答

绝对是黑客，但是我对自动生成的config.h文件进行了后处理：

sed -e 's/.*PACKAGE_.*//' < config.h > config.h.sed && mv config.h.sed config.h

在我们的构建环境中，这是可以容忍的，但我会对更清洁的方式感兴趣。

回答

事实证明，在我的情况下，有一个非常简单的解决方案。供应商项目将几个头文件收集到一个整体的头文件中，然后由供应商源文件#include。但是构建整体头文件的make规则意外地包含了生成的config.h。整批标头中​​包含PACKAGE，VERSION等配置变量是导致重新定义警告的原因。事实证明，供应商的" config.h"是无关紧要的，因为" config.h"总是解析为" $(top_builddir)/config.h"。

我相信这就是它应该起作用的方式。默认情况下，子项目应包含封闭项目的config.h而不是其自身的，除非子项目明确包含其自身，或者操纵INCLUDE路径，以便其自身的目录位于$(top_builddir)之前，否则进行其他操纵头文件与我的情况相同。

回答

一些注意事项：

• 我们没有提到config.h是如何包含的-带有引号或者尖括号。有关差异的更多信息，请参见另一个问题。简而言之，通常在引号中包含" config.h"，而不是尖括号，这应使预处理器更喜欢项目自己目录中的" config.h"(通常是我们想要的)
• 我们说一个子项目应该包括封闭项目的config.h通常，这根本不是我们想要的。该子项目是独立的，并且其PACKAGE和VERSION应该是该子项目之一，而不是子项目。例如，如果在xmlreader项目中包含libxml，则仍然希望使用PACKAGE libxml和VERSION(无论libxml版本是什么)来编译libxml代码。
• 从公共头文件中包含config.h通常是一个很大的错误。 config.h始终是项目或者子项目的私有文件，并且仅应包含在.c文件中。因此，如果供应商的文档说要包括他们的" vendor.h"，而公共头文件以某种方式包括" config.h"，那么这是不行的。同样，如果项目是一个库，则不要在公共安装的头文件的任何地方包含" config.h"。