如何避免重新定义 VERSION、PACKAGE 等答案

【问题标题】：How to avoid redefining VERSION, PACKAGE, etc如何避免重新定义 VERSION、PACKAGE 等
【发布时间】：2010-09-05 15:55:38
【问题描述】：

我没有看到任何与 GNU autoconf/automake 构建相关的问题，但我希望至少你们中的一些人熟悉它。如下：

我有一个项目（我称之为 myproject），其中包含另一个项目（供应商）。供应商项目是由其他人维护的独立项目。像这样包含一个项目是相当的straightforward，但在这种情况下有一个小问题：每个项目都会生成自己的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 邮件列表上的 this 线程，这并没有太多帮助。还有其他人有更好的想法吗？

【问题讨论】：

标签： c linux unix autoconf automake

【解决方案1】：

一些注意事项：

您没有提到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。

【讨论】：

【解决方案2】：

这绝对是一个 hack，但我对自动生成的 config.h 文件进行了后处理：

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

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

【讨论】：

【解决方案3】：

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

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

【讨论】：