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 回答