避免重复 GNU Make 规则
我一直在编写一个执行一些依赖项生成的 Makefile,我发现自己必须重复规则,因为(遗留)代码库包含 .cpp
和 .cc
文件。好像有点难看。无论如何,是否可以指定目标的先决条件可以是 .cpp
或 .cc
文件?
因此,而不是:
%.d : %.cpp
$(CPP) -MM $(CPPFLAGS) $<
%.d : %.cc
$(CPP) -MM $(CPPFLAGS) $<
创建一些没有重复的东西,例如:
%.d : %.(cpp | cc)
$(CPP) -MM $(CPPFLAGS) $<
或者这种强制冗余只是 GNU Make 设计中的一个不幸的元素?
I've been writing a Makefile that performs some dependency generation and I've found myself having to duplicate rules because the (legacy) codebase contains a mixture of .cpp
and .cc
files. It seems a bit unsightly. Is there anyway to specify that the prerequisites of a target can be either .cpp
or .cc
files?
So rather than having:
%.d : %.cpp
$(CPP) -MM $(CPPFLAGS) lt;
%.d : %.cc
$(CPP) -MM $(CPPFLAGS) lt;
Create something without the duplication like:
%.d : %.(cpp | cc)
$(CPP) -MM $(CPPFLAGS) lt;
Or is this enforced redundancy just an unfortunate element of GNU Make's design?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
第一个选项,使用变量定义一次规则主体,并根据需要重用它:
第二个选项,使用
$(eval)
动态生成规则:First option, use a variable to define the rule body once, and reuse it as needed:
Second option, use
$(eval)
to dynamically generate the rules:这应该可行:
另一个想法:
另一个想法是让 GNU make 生成两个模式规则。
本质上有两种方法可以做到这一点:
%-cc.mk
或类似文件),使用 GNU make 的include
语句$(eval)
和$(call)
函数内联评估它们 与C/Unix 开发工具链中的大多数其他内容一样,这些技术本质上是一种预处理形式,使他们易于理解,但代价是很难使用(大量的双重或三重转义,真的很难跟踪何时扩展的内容;调试可能是一种巨大的痛苦,至少根据我的经验)。
因此,将它们保留用于更复杂的用例(其中 Stack Overflow 列出了一些)。
This should work:
Another idea:
Another idea is to make GNU make generate the two pattern rules.
There are essentally two ways of doing this:
%-cc.mk
or similar) that you include within your actual makefile with GNU make'sinclude
statement$(eval)
and$(call)
functionsLike most everything else in the C/Unix development toolchain, these techniques are essentially a form of preprocessing, making them easy to understand at the price of being really hard to use (lots of double or triple escaping, really hard to keep track of what is expanded when; debugging can be a royal pain, at least in my experience).
So reserve them for more complicated use cases (of which Stack Overflow lists a few).