R..*_*R.. 18 c autoconf makefile build configure
我不是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或在其他一些通过使变量？如果它们与用户提供的标志冲突CFLAGS怎么办？
我可以看到很多项目的答案应该只是"根本不要弄乱它并让用户选择他们的CFLAGS",但我的一些使用案例是用户群通常感兴趣的项目开箱即用的优化和调试配置.
编辑:我忘记的另一个问题:当涉及到检测并自动使用某些不是必需但首选的CFLAGS时,是否应该仅在用户CFLAGS在环境中留空时,或者总是这样做？
如果你想处理像--enable-warnings这样的论点,你还有很多工作要做.如果你想保持简单,你可以让这个参数添加类似的东西
CFLAGS="$CFLAGS -Wall -Wextra"; CPPFLAGS="$CPPFLAGS -DWARNINGS"
在您的配置脚本中,但这实际上打开了一大堆蠕虫.这些选项是否被所有编译器识别,或者您假设您的用户使用的编译器识别这些选项并且他们按照您的意愿执行操作？您可能需要将该分配包装在另一个检查中,以获取您知道的一组编译器.或者您需要检查用户使用的编译器在传递这些标志时是否至少没有错误(可能用户已经在CFLAGS中设置了-Wsome,并且编译器将使用冲突的参数错误输出 - Wall.)同样的问题适用于--enable-debug.通过将-DEBUG附加到CPPFLAGS来响应--enable-debug似乎是完全合理的,因此用户不需要检查您的源以确定是否通过-DEBUG而不是-DDEBUG启用调试,但您无法预测所有情况和通常最好在谨慎方面犯错而不要做这些事情.
如果您希望用户具有"开箱即用的优化和调试配置",则项目的配置脚本是错误的.保持配置简单,并让您的用户使用像pkgsrc这样的包管理系统.如果您希望您的发行版tarball具有某些功能,请提供一组脚本(可能在检测到平台后由配置脚本自动调用,但提供覆盖该功能的功能),以便为用户和从而提供所需的功能.但是让配置脚本本身保持简洁.