makefile - gnumake 和模式规则

Question

我正在使用 GNUmake 从源目录生成一些 Web 内容的部署版本。我想成为通过压缩工具(例如 YUI 压缩器)运行某些文件的规则，然后对于没有规则的任何内容，只需复制它。

例如:

# Rule with all the $(WWW_OUT_DIR)/*.* files as a prerequisite
all: $(WWW_OUT_FILES)

# Generic rule to perform compression on Javascript files.
$(WWW_OUT_DIR)/%.js:     $(WWW_SRC_DIR)/%.js
    $(YUI_COMP) $(YUI_COMP_OPTS) $< > $@

# Generic rule to perform compression on CSS files.
$(WWW_OUT_DIR)/%.css:    $(WWW_SRC_DIR)/%.css
    $(YUI_COMP) $(YUI_COMP_OPTS) $< > $@

# TDB Rule to magically handle everything else? (This doesn't work)
$(WWW_OUT_DIR)/%.%:   $(WWW_SRC_DIR)/%.%
    cp $< $@

我如何完成最后一条规则试图做的事情？ IE。对于 $(WWW_OUT_FILES) 中不是 .js 或 .css 的所有内容，只需复制它？如果可能，我想保留对相应输入文件的依赖。

Answer 1

你几乎是对的，唯一需要修复的是最后一个模式规则，只需删除多余的百分比符号:

$(WWW_OUT_DIR)/%:   $(WWW_SRC_DIR)/%
    cp $< $@

还要记住，从 GNU Make 3.82 开始，模式搜索算法已经修改了一点(来自 Changelog):

The pattern-specific variables and pattern rules are now applied in the shortest stem first order instead of the definition order (variables and rules with the same stem length are still applied in the definition order). This produces the usually-desired behavior where more specific patterns are preferred.

如果您使用最新版本的 Make，这正是您想要的。为了让您的 Makefile 与其他版本的 GNU Make(包括 3.82 之前的版本)兼容，必须在其他版本之后定义规则(如原始问题中所示)。

更新。

来自 here 的一个很好的例子:

Prior to version 3.82, when gmake finds multiple matches during a pattern search, it prefers patterns declared earlier in the makefile over patterns declared later. As of 3.82, gmake instead prefers the pattern that results in the shortest stem. That sounds a bit confusing thanks to the jargon, but I think this will actually cause gmake to better adhere to the principle of least astonishment. Here’s an example:

all: sub/foo.x

%.x:
    @echo "Prefer first match (stem is $*)."

sub/%.x:
    @echo "Prefer most specific match (stem is $*)."

Compare the output from gmake 3.81 and 3.82:

• gmake 3.81

  Prefer first match (stem is sub/foo).
  

• gmake 3.82

  Prefer most specific match (stem is foo).
  

gmake 3.82 prefers the second pattern because it is a more specific match than the first. Note that this is a significant backwards-incompatibility compared with previous versions of gmake!