为什么环境变量默认情况下不覆盖 makefile 中设置的变量？
我正在编译软件包，我发现 Makefile 作者经常在 makefile 中编写设置 CFLAGS，并带有这样那样的选项。另一方面，我想尝试一些编译器优化，并希望传播编译器开关以尽可能减少麻烦。但这并不总是可行的。例如，当 makefile 指定 CFLAGS 并且我希望所有 C 编译器调用都使用 -fomit-frame-pointer 时，无需显式编写类似 CFLAGS=-fomit-frame-pointer make 的内容，那么什么是我的选择并不黑客。从我所看到的，有上面的内容，然后有相同但不同的 make "CFLAGS=-fomit-frame-pointer" 我也可以做我认为最好的解决方案和这个问题的原因：
export CFLAGS=-fomit-frame-pointer
make -e
我认为这是最好的一个，因为坦率地说，即使考虑到潜在的危险标志，我也不会太多地调试软件，当我需要时，我可以根据需要重新编译特定的部分，并提供调试信息等。否则，我喜欢使用发布软件，根本不需要调试花哨的东西，特别是如果包不是由我编写的。所以我想我在这里具体要问的是：为什么 make 不会自动选择环境变量而不是 makefile 自己的环境变量？毕竟环境最了解什么是什么，并且如果作者确实需要按照自己的方式进行某些操作，那么可以使用“覆盖”语法，对吗？
I am compiling packages and I see that oftentimes Makefile authors write set CFLAGS in the makefile, with such and such options. I, on the other hand, would like to try out some compiler optimizations and would like to propagate the compiler switches to make with as little trouble as possible. Not always is this doable though. For instance when a makefile specifies CFLAGS and I want all C compiler invocations to use -fomit-frame-pointer, short of having to explicitly write something like CFLAGS=-fomit-frame-pointer make, what are my options that are not hackish. From what I can see there is the above, then there is the same but different make "CFLAGS=-fomit-frame-pointer" and I can also do what I consider to be the best solution and the reason for this question:
export CFLAGS=-fomit-frame-pointer
make -e
I consider this the best one, because frankly even thought potentially dangerous flag, I don't debug software that much, and when I need to I can recompile a particular piece on demand, with debugging info and all. Otherwise I like to work with release software without debugging bells and whistles at all, especially if the package is not authored by me. So I guess what I ask here specifically is: why make does not automatically prefer environment variables to makefile's own? After all environment knows best what is what, and in case make author really needs to have something their way there is the 'override' syntax, right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您将变量放在 make 命令行上，Make将覆盖这些变量。
试试这个：
make CFLAGS=-fomit-frame-pointer一句警告。大多数 Makefile 不希望它们的变量被覆盖。这意味着如果 Makefile 使用 CFLAGS 指定 -I 表示包含文件、-O2 表示优化或其他标志，则必须将它们添加到 CFLAGS 覆盖中，否则 make 可能会失败。
Make will override the variables if you put them on the make command line.
Try this:
make CFLAGS=-fomit-frame-pointerOne word of warning. Most Makefiles don't expect their variables to be overridden. That means that if the Makefile uses CFLAGS to specify -I for include files, -O2 for optimization, or other flags, you must add them to your CFLAGS override or the make will probably fail.
这是有争议的：“毕竟环境最了解什么是什么”，
这就像对一个已经长大的孩子说“母亲最了解”并阻止他们去学习法律，因为你想看看他们会成为什么样的水管工。这是他们的生活。放手吧，让他们自己做选择。
哦等等，你问的是环境和制造。正确的。
嗯，make 是一个新的过程，在您修改环境后开始，在一般情况下，环境不知道 make 的目标是什么以及它如何工作。因此，无论 make 显式设置什么，都应该胜过环境中可能发生的任何情况。
更新：我最初在答案中遗漏了一个论点——可预测性。唯一的要求应该是存在标准化的工具集（相同版本的 GCC，相同的库），并且考虑到正确编写的 make 文件应该始终产生相同的结果，无论环境是什么，或者存在什么其他工具。
That is arguable: "After all environment knows best what is what"
It's like saying "mother knows best" to an all-grown up child and stopping them from going to study law because you wanted to see what kind of plumber they'd be. It's their life. Let go and let them make their choice for themselves.
Oh wait, you were asking about environment and make. Right.
Well, make is a new process that starts after you've modified your environment and in the general case, the environment does not know what the make goals are and how it works. So, whatever make explicitly sets should trump whatever might happen to be in the environment.
Update: There's an argument I missed originally in my answer - predictability. The only requirement should be the presence of standardized set of tools (same version of GCC, same libs), and given that a properly written make file should always produce the same result, no matter what the environment is, or what other tools are present.