我不是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变量？如果它们与用户提供的CFLAGS中的标志冲突怎么办？
我可以看到很多项目的答案应该只是“根本不要弄乱它并让用户选择他们的CFLAGS”，但我的一些使用案例是用户群通常对开箱即用的优化和调试配置感兴趣。
编辑：我忘记了另一个问题：当涉及到检测并自动使用某些非必要但首选的CFLAGS时，仅当用户将CFLAGS留空时才应执行此操作在环境中，还是总是？
答案 0 :(得分：8)
如果你想处理像--enable-warnings这样的论点，你还有很多工作要做。如果你想保持简单，你可以让这个参数添加类似
的东西CFLAGS="$CFLAGS -Wall -Wextra"; CPPFLAGS="$CPPFLAGS -DWARNINGS"
在您的配置脚本中，但这实际上会打开一大堆蠕虫。这些选项是否被所有编译器识别，或者您假设您的用户使用的编译器识别这些选项并且他们按照您的意愿执行操作？您可能需要将该分配包装在另一个检查中，以获取您知道的一组编译器。或者您需要检查用户使用的编译器在传递这些标志时是否至少没有错误（可能用户已经在CFLAGS中设置了-Wsome，并且编译器将使用冲突参数错误输出 - Wall。）同样的问题适用于--enable-debug。通过将-DEBUG附加到CPPFLAGS来响应--enable-debug似乎是完全合理的，因此用户不需要检查您的源以确定是否通过-DEBUG而不是-DDEBUG启用调试，但您无法预测所有情况和通常最好小心谨慎，不做这些事情。
如果您希望用户拥有“开箱即用的优化和调试配置”，项目的配置脚本就是错误的位置。保持配置简单，并让您的用户使用像pkgsrc这样的包管理系统。如果您希望您的发行版tarball具有某些功能，请提供一组脚本（可能在检测到平台后由配置脚本自动调用，但提供覆盖该功能的功能），以便为用户和从而提供所需的功能。但请保持配置脚本本身不存在。
答案 1 :(得分：1)
在提供自定义标志时，让用户期望必须与事物搏斗是足够的。 CFLAGS可以追加，CPPFLAGS可以预先（标题搜索路径选项查看第一个路径，而编译器优化和指令查看 last 选项（或者更确切地说，它们覆盖先前的选项））
--enable-debug以及提供给configure脚本的其他命令行指令不仅需要更改编译器选项，还可以在源代码中更改内容（例如，可能重新定义内联宏）作为实际的功能），所以它们的用途有些不同。
总之，用户指定的CPPFLAGS前置，附加用户指定的CFLAGS;任何configure脚本选项都可以根据上下文进行追加或预先添加。