为什么环境变量默认不覆盖makefile中设置的变量？

Question

我正在编译包,我看到Makefile作者经常在makefile中写入设置CFLAGS,有这样的选项.另一方面,我想尝试一些编译器优化,并希望传播编译器开关以尽可能少地解决问题.但这并不总是可行的.例如,当makefile指定CFLAGS并且我希望所有C编译器调用都使用-fomit-frame-pointer时,不必显式地写出类似的内容CFLAGS=-fomit-frame-pointer make,那些不是hackish的选项.从我所看到的有上述,然后有相同但不同的make "CFLAGS=-fomit-frame-pointer"我也可以做我认为是最好的解决方案和这个问题的原因:

export CFLAGS=-fomit-frame-pointer
make -e

我认为这是最好的一个,因为坦率地甚至认为有潜在危险的标志,我不会调试那么多软件,当我需要时我可以根据需要重新编译一个特定的部分,调试信息和所有.否则我喜欢使用发布软件而不需要调试铃声和口哨,特别是如果包不是由我编写的.所以我想我具体要问的是:为什么make不会自动更喜欢makefile自己的环境变量？在所有环境都知道什么是最好的情况之后,如果作者确实需要他们的方式,那么就有'覆盖'语法,对吧？

Answer 1

如果将变量放在make命令行上,Make 将覆盖变量.

试试这个: make CFLAGS=-fomit-frame-pointer

一句警告.大多数Makefile都不希望它们的变量被覆盖.这意味着如果Makefile使用CFLAGS为包含文件指定-I,为优化指定-O2或其他标志,则必须将它们添加到CFLAGS覆盖中,否则make可能会失败.

Answer 2

这是有争议的:"毕竟环境最清楚什么是什么"

就像对一个成年的孩子说"妈妈最了解"并阻止他们去学习法律一样,因为你想看看他们是什么样的水管工.这是他们的生活.放手让他们自己做出选择.

哦等等,你问的是环境和制造.对.

嗯,make是一个新的过程,在您修改环境后开始,在一般情况下,环境不知道制作目标是什么以及它是如何工作的.因此,无论制作什么明确设置都应该胜过环境中可能发生的事情.

更新:我的回答中最初错过了一个论点 - 可预测性.唯一的要求应该是标准化的工具集(相同版本的GCC,相同的库)的存在,并且假定正确编写的make文件应该总是产生相同的结果,无论环境是什么,或者存在什么其他工具.