18

我不是 autoconf 的粉丝，但为了最不意外的原则，我试图让我的（非 autoconf）配置脚本的行为尽可能接近用户对基于 autoconf 的构建系统的期望。GNU 编码标准在这个主题上实际上是相当合理的，并明确提到不使用 autoconf/automake 而是以另一种方式提供兼容接口的可能性：

https://www.gnu.org/prep/standards/standards.html#Configuration

然而，我找不到任何好的描述的一个问题是如何最好地处理 CFLAGS。我很清楚，任何与用户无关的基本标志（如-I$(srcdir)/inc）都不属于配置脚本或 makefile 中的 CFLAGS，因为覆盖它们会完全破坏构建。所以这些我要么在makefile中硬编码，要么（如果它们需要一些检测）将检测逻辑放在configure中，但是通过一个单独的make变量而不是CFLAGS传递它们，这样它们就不会被覆盖。

不过，我仍然不清楚如何最好地处理是可选的东西，比如优化级别/选项、警告标志、调试等。标志应该由诸如此类的东西启用，--enable-debug或者--enable-warnings添加到CFLAGS或传递到其他一些 make 变量中吗？如果它们与 user-provided 中已经存在的标志冲突CFLAGS怎么办？

我可以看到很多项目的答案可能应该是“根本不要弄乱它，让用户选择他们的CFLAGS”，但我的一些用例是用户群通常有兴趣的项目开箱即用的优化和调试配置。

编辑：我忘记的另一个问题：在检测和自动使用某些非必需但首选的 CFLAGS 时，是否应该仅在用户CFLAGS在环境中留空时才这样做，还是总是？

4

2 回答 2

8

如果你想处理像 --enable-warnings 这样的参数，你有很多工作要做。如果你想保持简单，你可以让那个参数添加类似

CFLAGS="$CFLAGS -Wall -Wextra"; CPPFLAGS="$CPPFLAGS -DWARNINGS"

在您的配置脚本中，但这实际上会打开一大堆蠕虫。这些选项是否被所有编译器识别，或者您是否假设您的用户使用的编译器可以识别这些选项并且他们可以按照您的意愿进行操作？可能您需要将该分配包装在另一个检查中，以检查您知道的一组编译器。或者您需要检查用户使用的编译器在传递这些标志时至少不会出错（也许用户已经在 CFLAGS 中设置了 -Wsome，并且编译器将使用冲突的参数出错 -墙。）同样的问题也适用于 --enable-debug。通过将 -DEBUG 附加到 CPPFLAGS 来响应 --enable-debug 似乎是完全合理的，因此用户不需要检查您的源来确定是否通过 -DEBUG 而不是 -DDEBUG 启用了调试，不要做这样的事情。

如果您希望您的用户拥有“开箱即用的优化和调试配置”，那么项目的配置脚本是错误的地方。保持配置简单，让用户使用像 pkgsrc 这样的包管理系统来处理这些事情。如果您希望您的分发 tarball 具有某些功能，请为为用户和从而提供所需的功能。但是请保持配置脚本本身的基本内容。

于 2012-05-02T13:14:28.707 回答
1

让用户期望在提供自定义标志时不得不与事情搏斗是足够理智的。CFLAGS可以附加，CPPFLAGS可以附加（标题搜索路径选项查看第一个路径，而编译器优化和指令查看最后一个选项（或者更确切地说，它们覆盖先前的选项））

--enable-debug也许提供给配置脚本的其他命令行指令不仅需要更改编译器选项，而且还可能更改源代码中的内容（例如，将内联宏重新定义为实际函数），因此它们的用途有些不同。

总之，有用户指定的CPPFLAGS前置，用户指定的CFLAGS附加；根据上下文，任何配置脚本选项都可以附加或附加。

于 2012-05-02T17:07:30.640 回答