是否应该在 Makefile 中覆盖 CXXFLAGS、CPPFLAGS 和 LDFLAGS？答案

【问题标题】：Should CXXFLAGS, CPPFLAGS and LDFLAGS be overridden in a Makefile?是否应该在 Makefile 中覆盖 CXXFLAGS、CPPFLAGS 和 LDFLAGS？
【发布时间】：2018-08-11 22:43:06
【问题描述】：

情况

我正在使用手写的 GNUmakefile，其中 CXXFLAGS、CPPFLAGS 和 LDFLAGS 由 += 赋值附加，如：

CXXFLAGS    += -std=c++11 $(MODENV) $(WARNINGS) $(OPTIMS)
CPPFLAGS    += $(DMACROS) $(INCDIRS)
LDFLAGS     += $(MODENV) $(LIBDIRS) $(EXTRA_LIBS)

问题

当用户在命令行定义自己的标志时，Makefile 中的附加将被忽略。这使变量完全由用户设置。（在我的情况下，构建将失败。）这个问题的通用解决方案是override the variables，如：

override CXXFLAGS   += -std=c++11 $(MODENV) $(WARNINGS) $(OPTIMS)
override CPPFLAGS   += $(DMACROS) $(INCDIRS)
override LDFLAGS    += $(MODENV) $(LIBDIRS) $(EXTRA_LIBS)

这样，必要的内容将被附加到用户的变量中。

问题

覆盖变量是否被视为不好的做法？
在 Makefile 中设置上述标志是否被视为不好的做法？
如果上述两个问题都“是”，那么我应该把-std=c++11 放在哪里，如果不是放在CXXFLAGS 中？

【问题讨论】：

如果您的构建在没有给定标志的情况下失败，那么这是完全可以接受的，尽管如果有人乱用构建标志，如果他们想进行更改，您不妨要求他们自己编辑 makefile。跨度>

标签： makefile gnu-make

【解决方案1】：

如果用户覆盖了变量，假设用户知道他们在做什么。他们正在处理的系统可能有非常不同的要求，并且需要覆盖变量。不要让困难变得不可能。

【讨论】：

我自己有reached the same conclusion：将内容附加到用户提供的标志以便更轻松地构建是一个良好的意图，它将为 Makefile 修补地狱铺平道路。

【解决方案2】：

我不打算评论好的/坏的做法，因为它取决于用例（这个makefile的用户是谁？他们都和你一起工作吗，所以你可以告诉他们它的意思用过吗？你能在makefile cmets 或项目README 中记录你的约定吗？）

但是……

如果不在CXXFLAGS 中，我应该把-std=c++11 放在哪里？

如果您有必要的标志并且不能被用户覆盖，您可以找到另一种方法将它们放入编译命令中。

例如：

CXX := g++ -std=c++11

或者：

foo.o: foo.cc
        $(CXX) $(CPPFLAGS) $(CXXFLAGS) -std=c++11 -o $@ $^

更好的办法是使用一个变量，这样它仍然可以由用户设置（例如，使用-std=c++14 代替）但不是由CXXFLAGS 设置：

STD := -std=c++11
foo.o: foo.cc
        $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(STD) -o $@ $^

（或者只是将-std 选项放在CXXFLAGS 之前，以便CXXFLAGS 中的不同std 选项优先）。

【讨论】：

【解决方案3】：

由于make 的构建管理用例如此多样化，因此根本没有理由客观地将其判断为“不良做法”。如果您正在为众多平台以及未知的受众和时间框架编写 OSS，则应使用POLA/POLS。也就是说，一个用户惊讶地发现比她在命令行上给出的标志更多的标志是一个相当不切实际的极端情况，所以-override 有它的位置。最后，您添加的值对于构建是绝对必要的，不是吗？

PS：POLA 当然应该适用于所有工程活动——只是“惊喜”的定义会随着相关任务的变化而变化。

【讨论】：