9

我还没有看到任何与 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 搜索找到的唯一相关信息是automake 邮件列表上的这个线程,这并不是很多帮助。还有其他人有更好的想法吗?

4

3 回答 3

5

一些注意事项:

  • 你没有提到如何config.h包含 - 带引号或尖括号。有关差异的更多信息,请参阅this other question。简而言之,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在公开安装的标头中包含任何地方。
于 2008-08-25T21:52:23.997 回答
2

这绝对是一个黑客,但我对自动生成的config.h文件进行了后处理:

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

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

于 2008-08-12T20:18:22.180 回答
1

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

我相信这是它应该工作的方式。默认情况下,子项目应该包含封闭项目config.h而不是它自己的,除非子项目明确包含它自己的,或者操纵 INCLUDE 路径以使其自己的目录位于之前$(top_builddir),或者像我的情况一样操纵头文件。

于 2008-08-14T16:16:56.203 回答