如何避免重新定义VERSION,PACKAGE等

lsint 发布于 2018-03-15 autoconf 最后更新 2018-03-15 01:02 523 浏览

我还没有看到任何有关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线程,这不是一大帮忙。其他人有更好的想法吗?
已邀请:

xporro

赞同来自:

这绝对是一个黑客,但我后处理自动config.h文件:

sed -e 's/.*PACKAGE_.*//' < config.h > config.h.sed && mv config.h.sed config.h
这在我们的构建环境中是可以忍受的,但我会对更干净的方式感兴趣。

lsint

赞同来自:

事实证明,在我的情况下有一个非常简单的解决方案。供应商项目将几个头文件收集到一个单片头文件中,然后由供应商来源进行#included。但是构建整体式标题的make规则意外地包含了生成的config.h。在单片头中存在PACKAGE,VERSION等配置变量是导致重新定义警告的原因。事实证明,供应商的config.h是不相关的,因为“config.h”总是解析为$(top_builddir)/config.h。 我相信这是它应该工作的方式。默认情况下,子项目应该包含封闭项目的config.h而不是自己的项目,除非子项目明确包含它自己的项目,或者操作INCLUDE路径以使其自己的目录位于$(top_builddir)之前,否则就像我的情况那样处理头文件。

baut

赞同来自:

一些说明:

  • 你没有提到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