[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Pattern rule precedence when inside definitions

From: Moshagen Sjur Nørstebø
Subject: Pattern rule precedence when inside definitions
Date: Tue, 8 Mar 2016 21:07:40 +0000


I am not able to get make to behave the way I want. This is my setup:

In A:

define giella_generators
generator-gt-%.$(1): generator-gt-%.tmp.$(1) \
filters/remove-derivation-position-tags.$(1) \
        $$(AM_V_XFST_TOOL)$$(PRINTF) "read regex \
                                @\"filters/make-optional-coll-tags.$(1)\"     \
                        .o. @\"filters/make-optional-lang_hom-tags.$(1)\" \
                        .o. @\"filters/remove-derivation-position-tags.$(1)\" \
                        .o. @\"$$<\"                                      \
                 save stack address@hidden
                 quit\n" | $$(XFST_TOOL)
$(foreach fst,hfst xfst foma,$(eval $(call giella_generators,$(fst))))

# include file B:
include $(top_srcdir)/am-shared/

In file B:

define giella_default_generators
generator%.$(1): generator%.tmp.$(1)
        $$(AM_V_XFST_TOOL)$$(PRINTF) "\
                 load stack $$<\n\
                 save stack address@hidden
                 quit\n" | $$(XFST_TOOL)
$(foreach fst,hfst xfst foma,$(eval $(call giella_default_generators,$(fst))))

I want to build a file named:


Expected behaviour:

The target file should be built using the receipt in File A, both because the 
pattern is more specific, and because that target appears earlier in the 
(Automake expanded actual) makefile. Ie by using a more specific pattern, I 
should be able to override the more general pattern in the included file. 
Pattern targets with equal stems (should not be the case here) are evaluated on 
a first come basis, which again should achieve the same result. But no:

Actual behaviour:

The target is built using the rule in File B.

Additional observation:

I get the expected behaviour if I skip the define construction, and just use 
plain pattern rules. However, this leads to a lot of duplicate code, which I 
would like to avoid. The use of definitions have been working fine in other 
cases, but this is the first time I have tried to use this exact combination of 
a pattern rule override within a definition.

I have tested with both ‘make’ (GNU Make from Apple, see version info below), 
and with the newest GNU Make (installed as gmake via MacPorts, see version info 
below). Both display the exact same unexpected behavior.

Am I doing something wrong, or is this a bug in Make, or is it a known 

Irrespective of cause, how can I get the intended behavior?

Version info:

$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

This program built for i386-apple-darwin11.3.0

$ gmake --version
GNU Make 4.1
Built for x86_64-apple-darwin15.3.0
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Sjur N. Moshagen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]