【问题标题】:When ./configure is given conflicting options, which wins?当 ./configure 给出冲突的选项时,哪个会赢?
【发布时间】:2013-05-19 18:47:09
【问题描述】:

我正在使用buildroot 构建一个交叉编译的 gcc,并且可以为 ./configure 步骤提供一些额外的配置选项,而无需修补 buildroot 源。但是,我想覆盖 buildroot 源已经明确设置的选项。具体来说,buildroot 源有:

$(GCC_SRC_DIR)/configure $(QUIET) \
--prefix=/usr \
...
--disable-__cxa_atexit \
...
$(EXTRA_GCC_CONFIG_OPTIONS)

我希望将--enable-__cxa_atexit 放入$EXTRA_GCC_CONFIG_OPTIONS 并以此为荣。

我猜如果buildroot 的makefile 设计得足够好,那么这实际上就是会发生的。但我正在尝试验证是否如此(在文档中,而不是通过反复试验),并且无法找到将冲突选项传递给 ./configure 脚本时会发生什么的任何规范。

所有基于自动工具的配置脚本都会以同样的方式处理这个问题吗?或者 gcc 可能以一种方式处理它,并且(例如)binutils 以不同的方式处理它?

我希望 SO 上的其他人必须在我之前找到此问题。但是我的 google-fu 和 SO-fu 什么都没有。

【问题讨论】:

  • autoconf 非常灵活且令人难以置信的滥用,多年来成千上万的开发人员严重滥用它,因此configure 脚本几乎没有一致性。在所有生成的configure 脚​​本中都不会看到您可能期望的任何行为!

标签: gcc configure autotools


【解决方案1】:

相关文档是来自 GNU 编码标准的 How Configuration Should Work 和来自 Autoconf 手册的 Running configure Scripts / Optional Features

他们没有提到冲突的选项,所以我们只需要检查生成的 configure 脚本中的 shell 代码。我用 Autoconf 2.69 制作的脚本只是按顺序处理--enable-foo--disable-foo 选项并分配给enable_foo,因此后一个选项简单地获胜。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-08-04
    • 2015-08-20
    • 2021-07-14
    • 2017-09-13
    • 1970-01-01
    相关资源
    最近更新 更多