我不是 autoconf 的粉丝，但为了最不意外的原则，我试图让我的(非 autoconf)配置脚本的行为尽可能接近用户对基于 autoconf 的期望构建系统。 GNU 编码标准在这个话题上实际上是相当合理的，并且明确提到了不使用 autoconf/automake 而是以另一种方式提供兼容接口(interface)的可能性:
https://www.gnu.org/prep/standards/standards.html#Configuration
但是，我找不到任何好的描述的一个问题是如何最好地处理 CFLAGS。我很清楚，任何与用户无关的 essential 标志(如 -I$(srcdir)/inc)都不属于配置中的 CFLAGS脚本或makefile，因为覆盖它们会完全破坏构建。所以这些我要么在 makefile 中硬编码，要么(如果他们需要一些检测)将检测逻辑放在配置中，但通过单独的 make 变量而不是 CFLAGS 传递它们，这样它们就不会被覆盖。
不过，我仍然不清楚如何最好地处理可选的东西，如优化级别/选项、警告标志、调试等。应该由 --enable-debug 之类的东西启用标志> 或 --enable-warnings 被添加到 CFLAGS 或传入其他一些 make 变量？如果它们与用户提供的 CFLAGS 中已有的标志冲突怎么办？
我可以看到很多项目的答案可能只是“不要乱用它，让用户选择他们的 CFLAGS”，但我的一些用例是用户群通常对开箱即用的优化和调试配置感兴趣的项目。
编辑:我忘记的另一个问题:当涉及到检测和自动使用某些非必需但首选的 CFLAGS 时，是否应该仅在用户离开 CFLAGS 在环境中为空，还是始终为空？
最佳答案
如果你想处理像 --enable-warnings 这样的参数，你有很多工作要做。如果你想保持简单，你可以让那个参数添加类似
CFLAGS="$CFLAGS -Wall -Wextra"; CPPFLAGS="$CPPFLAGS -DWARNINGS"
在您的配置脚本中，但这实际上会打开一大堆蠕虫。这些选项是否被所有编译器识别，或者您是否假设您的用户使用的编译器可以识别这些选项并且他们可以按照您的意愿进行操作？可能您需要将该分配包装在另一个检查中，以检查您知道的一组编译器。或者您需要检查用户使用的编译器在传递这些标志时至少不会出错(也许用户已经在 CFLAGS 中设置了 -Wsome，并且编译器将使用冲突的参数出错 -墙。)同样的问题也适用于 --enable-debug。通过将 -DEBUG 附加到 CPPFLAGS 来响应 --enable-debug 似乎是完全合理的，因此用户不需要检查您的源来确定是否通过 -DEBUG 而不是 -DDEBUG 启用了调试，但您无法预测所有情况和通常最好谨慎行事，并且不要这样做。
如果您希望您的用户拥有“开箱即用的优化和调试配置”，则项目的配置脚本是错误的地方。保持配置简单，让用户使用像 pkgsrc 这样的包管理系统来处理这些事情。如果您希望您的分发 tarball 具有某些功能，请为为用户和从而提供所需的功能。但请保留配置脚本本身的基本内容。
关于c - 在配置脚本中处理 CFLAGS 的最佳实践？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10404746/