如果您的项目包含configure.ac和许多Makefile.am文件，则可以传递用户变量（如CFLAGS）以配置为
CFLAGS = DEBUG_OPTIONS ./configure
但是，如果在configure.ac中，你有一个类似的语句 CFLAGS = NON_DEBUG_OPTIONS（你可以假设这是在AC_PROG_CC之后） 最终的对象是否可以调试？
答案 0 :(得分：0)
从Autoconf的角度来看，CFLAGS is an output variable就像你的configure.ac通过AC_SUBST宏明确声明的那样。输出变量的细节在Autoconf文档中有点散布，但基本上是
[they]是shell变量，其值被替换为文件 配置输出。
（Autoconf manual, section 7.2）
AC_PROG_CC宏为CFLAGS提供默认值，如果该变量尚未设置（例如来自环境）;否则，它会保持值不变。这就是为什么通过您显示的方式在命令行上将CFLAGS和某些其他输出变量指定给Autoconf configure脚本通常是有效的 - 它是导致变量绑定的标准shell语法放在正在运行的命令的环境中。
手册继续说，
[作为输出变量]意味着
AC_OUTPUT替换了“@variable@”的实例 输入文件 shell变量variable具有的值AC_OUTPUT被称为。
（强调补充。）尽管在AC_SUBST宏的文档中，它适用于预设输出变量，与通过AC_SUBST设置的变量相同。因此，如果configure在CFLAGS之前为AC_OUTPUT分配新值，则分配的最后一个值是替换为您的Makefile的值。在直接回答您的问题时，您描述的情况将导致使用非调试选项进行构建。
另请注意，这根本不是优先问题，因为只涉及一个变量。环境中设置的CFLAGS实际上是与configure脚本在内部访问和使用的相同变量，您可以在通过赋值进行修改，并最终替换为您的Makefile文件。因此，这是一个简单的操作顺序问题。
最后，我发现只有当你违反关于“用户变量”的Autotools原则时才会出现问题，例如CFLAGS。该变量的Autoconf文档就是这样说的：
有时包开发人员很想设置用户变量，例如
CFLAGS因为它似乎使他们的工作更容易。但是， 包本身永远不应该设置用户变量，尤其不要 包括正确编译所需的开关 封装 即可。由于这些变量被记录为包 建设者，该人理所当然希望能够覆盖任何一个 这些变量在构建时。如果包开发者需要添加 交换机不干扰用户，正确的方法 是引入一个额外的变量。 Automake让这一切变得简单 介绍AM_CFLAGS（参见标志变量排序），但概念 即使不使用Automake，也是一样的。
（强调补充。）
最后，请注意，用户可以始终通过在make命令行上设置值作为make的参数来覆盖输出变量或其他make变量，而不是或者另外将其指定为configure。