如何为单独的调试和发布构建目录创建目标？
我正在寻找在递归 makefile 系统中正确处理单独的调试和发布构建子目录的建议，该系统使用 gnumake 手册中记录的 $(SUBDIRS) 目标将 make 目标应用于（源代码）子目录。
具体来说，我对实现“全部”、“干净”、“真正干净”等目标的可能策略感兴趣，这些策略假设其中一棵树或应该对两棵树都起作用会导致问题。
我们当前的 makefile 使用一个 COMPILETYPE 变量，该变量设置为 Debug（默认）或 Release（“release”目标），它可以正确执行构建，但清理和 make all 只能在默认的 Debug 树上工作。 传递 COMPILETYPE 变量会变得很笨拙，因为是否以及如何执行此操作取决于实际目标的值。
I am looking for suggestions to properly handle separate debug and release build subdirectories, in a recursive makefile system that uses the $(SUBDIRS) target as documented in the gnumake manual to apply make targets to (source code) subdirectories.
Specifically, I'm interested in possible strategies to implement targets like 'all', 'clean', 'realclean' etc. that either assume one of the trees or should work on both trees are causing a problem.
Our current makefiles use a COMPILETYPE variable that gets set to Debug (default) or Release (the 'release' target), which properly does the builds, but cleaning up and make all only work on the default Debug tree. Passing down the COMPILETYPE variable gets clumsy, because whether and how to do this depends on the value of the actual target.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一种选择是在每种构建类型的子目录中都有特定的目标。 因此，如果您在顶层执行“make all”，它会查看 COMPILETYPE 并根据需要调用“make all-debug”或“make all-release”。
或者，您可以在顶层设置一个 COMPILETYPE 环境变量，并让每个子 Makefile 处理它。
真正的解决方案是不进行递归 make，而是将 makefile 包含在顶级文件的子目录中。 这将使您可以轻松地在与源所在的目录不同的目录中进行构建，因此您可以拥有 build_debug 和 build_release 目录。 它还允许并行 make 工作（make -j）。 有关完整说明，请参阅递归使人认为有害。
One option is to have specific targets in the subdirectories for each build type. So if you do a "make all" at the top level, it looks at COMPILETYPE and invokes "make all-debug" or "make all-release" as appropriate.
Alternatively, you could set a COMPILETYPE environment variable at the top level, and have each sub-Makefile deal with it.
The real solution is to not do a recursive make, but to include makefiles in subdirectories in the top level file. This will let you easily build in a different directory than the source lives in, so you can have build_debug and build_release directories. It also allows parallel make to work (make -j). See Recursive Make Considered Harmful for a full explanation.
如果您在 Makefile 中严格遵守使用 $(COMPILETYPE) 变量来引用所有规则中适当的构建目录（从生成对象文件的规则到 clean/dist/etc 的规则），那么您应该没问题。
在我参与的一个项目中，我们有一个 $(BUILD) 变量，该变量被设置为（相当于）build-(COMPILETYPE)，这使得规则变得更容易，因为所有规则都可以引用 $(BUILD)，例如，clean 将 rm -rf $(BUILD)。
只要您使用 $(MAKE) 调用子 make（并使用 GNU make），您就可以自动将 COMPILETYPE 变量导出到所有子 make，而无需执行任何特殊操作。 有关详细信息，请参阅GNU make 手册的相关部分。
其他一些选项：
--mode的值指定所需的构建标志在你的configure.ac中）如果你给出一些关于你的实际规则的更具体的例子，也许你会得到一些更具体的建议。
If you are disciplined in your Makefiles about the use of your $(COMPILETYPE) variable to reference the appropriate build directory in all your rules, from rules that generate object files, to rules for clean/dist/etc, you should be fine.
In one project I've worked on, we had a $(BUILD) variable that was set to (the equivalent of) build-(COMPILETYPE) which made rules a little easier since all the rules could just refer to $(BUILD), e.g., clean would rm -rf $(BUILD).
As long as you are using $(MAKE) to invoke sub-makes (and using GNU make), you can automatically exporting the COMPILETYPE variable to all sub-makes without doing anything special. For more information, see the relevant section of the GNU make manual.
Some other options:
cd /scratch/build/$COMPILETYPE && $srcdir/configure --mode=$COMPILETYPE && makewhich would take the build-type out of the Makefiles and into configure (where you'd have to add some support for specifying your desired build flags based on the value of--modein yourconfigure.ac)If you give some more concrete examples of your actual rules, maybe you will get some more concrete suggestions.