默认情况下，为什么环境变量不会覆盖makefile中设置的变量？

我正在编译软件包，我发现通常，Makefile作者在makefile中写入了设置CFLAGS，并带有这样和那样的选项。另一方面，我想尝试一些编译器优化，并希望传播编译器开关以尽可能少地麻烦。但这并不总是可行的。例如，当一个makefile指定CFLAGS，并且我希望所有的C编译器调用都使用-fomit-frame-pointer，因为缺少必须明确写出诸如CFLAGS=-fomit-frame-pointer make之类的东西，那么我的选项不是什么黑客。从我所看到，上面的，再有就是相同，但不同make "CFLAGS=-fomit-frame-pointer"，我还可以做什么，我认为是对这个问题的最佳解决方案和理由：默认情况下，为什么环境变量不会覆盖makefile中设置的变量？

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

我认为这是最好的一个，因为坦率地说，即使认为有潜在危险的标志，我也不会调试软件那么多，并且当我需要时，我可以根据需要重新编译特定的部分，包含调试信息和所有内容。否则，我喜欢使用发布软件，而不用调试花里胡哨的东西，特别是如果该包不是由我编写的。所以我想我在这里特别要问的是：为什么make不会自动将环境变量优先选择makefile？毕竟环境知道什么是最好的，为了让作者真的需要有自己的方式，有'覆盖'的语法，对吧？

来源

2010-07-02 amn

有一个参数需要做： - 环境覆盖，做你所描述的，我认为，所以你可以通过使用一个脚本调用真正的make - “environment” -overrides FWIW – rogerdpack 2014-07-10 14:28:56

这是值得商榷的：“毕竟环境最清楚什么是什么”

这就像说：“妈妈知道最好”到全长大的孩子，不去学习法律阻止他们，因为你想看看他们会是什么样的水管工。这是他们的生活。放手让他们为自己做出选择。

哦，等等，你问的是环境和问题。对。

好吧，make是一个新的过程，在你修改你的环境之后开始，并且在一般情况下，环境不知道make目标是什么以及它是如何工作的。所以，无论明确设置应该胜过可能发生在环境中的任何事情。

更新：在我的回答中，我最初错过了一个论点 - 可预测性。唯一的要求应该是存在标准化的工具集（GCC的相同版本，相同的库），并且考虑到正确编写的make文件应该始终产生相同的结果，而不管环境是什么，或者存在其他工具。

来源

2010-07-02 21:14:04

那么我们应该如何覆盖由make构建的软件的编译器开关？我的意思是以环保的方式？ :-)肯定会想要控制优化？你不能做出决定。如果有的话，使用CFLAGS/CXXFLAGS/CPPFLAGS硬编码的makefile并且不会让人改变这些，是不是很好设计？ – amn 2010-07-02 21:51:36

您可以更改makefile，或者在调用make时通过传递适当的标志作为命令行参数来覆盖它们。在这种情况下覆盖这些是来自用户的_explicit_动作。得到环境中发生的任何事情都可能导致不可预知的结果，因为用户可能甚至不知道他以前使用的程序对环境做了哪些修改 – 2010-07-02 22:43:28

那么这就是我的整个论点 - 环境知道最好。或者至少应该使用正确设计的Makefile。因此，这意味着如果Makefile在环境变量上中断，那就不好了。如果作者确实需要使用'-g'编译器开关，并担心生成文件用户可能会舍弃它，那么他们应该使用“覆盖”语法或第二阶段赋值“：=”？当您构建一整套软件包时，传递命令行标志并不是一个好的选择。 – amn 2010-07-03 09:29:25

制作将覆盖变量，如果你把它们放在make命令行上。

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

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

来源

2010-07-02 21:14:51

默认情况下，为什么环境变量不会覆盖makefile中设置的变量？

回答

相关问题