Follow-up Comment #2, bug #42125 (project make):
There is a space of inputs that is currently disallowed that could support
both multiple rule types:
1. a single target for each of multiple rules, and
2. a single rule having multiple targets
for both implicit and explicit rules.
The static pattern syntax could be extended to support implicit pattern rules,
changing
targets …: target-pattern: prereq-patterns … ; recipe
to
factors …: factors-pattern[=substitutions …]: prereq-patterns … ;
recipe
This would default to the current behaviour when [=substitutions]: is missing
Also, add support for %% at any place which would form implicit rules from
several factors in the same way that static pattern rules do
The meaning of rules of this form would be as follows
For each factor, one rule will be generated, that rule may have multiple
targets and multiple prerequisites as well as order-only prerequisites.
Double-percent '%%' will appear in the resulting per-factor rule as a single
percent '%' and thus the resulting per-factor rule will be an implicit rules
For each per-factor rule, its factor is matched against factors-pattern as
normal but the factors-pattern is substituted by the right-hand side of the
'=' sign as in patsubst in order to define one or more targets of that
per-factor rule.
If an equal sign '=' is not given then the behaviour is as if the equal sign
is given and the substitution is the factors-pattern is repeated to provide a
one-to-one mapping by default (eg "%.o" behaves as "%.o=%.o"). Thus the
default behaviour is the same as for the existing static pattern syntax
If an explicit rule is generated with multiple targets then the make
database lists each target separately in addition to its rule with a note that
it is a sibling of a multiple target rule in order to facilitate commandline
tab completion. The multiple target rule itself is listed as '# Not a target'
and '# Multiple targets' so that existing commandline tab completion is not
broken. Examples of commandline tab completion includes bash-completion.
eg:
build/x86-64/main.o build/x86/main.o build/armel/main.o: %.o=%.o: %.c ;
true
# same as build/x86-64/main.o build/x86/main.o build/armel/main.o: %.o: %.c
; true
# same as
# build/x86-64/main.o: build/x86-64/main.c ; true
# build/x86/main.o: build/x86/main.c ; true
# build/armel/main.o: build/armel/main.c ; true
x86-64 x86 armel: %=build/%/main.o: main.c ; true
# same as
# build/x86-64/main.o: main.c ; true
# build/x86/main.o: main.c ; true
# build/armel/main.o: main.c ; true
%%.o: %.o=%.o %.log .%.deps %.symbols: %.c ; true
# same as
# %.o %.log .%.deps %.symbols: %.c ; true
x86-64 x86 armel: %=build/%/%%.o log/%/%%.log .deps/%/%%.d
symbols/%/%%.symbols: %%.c ; true
# same as
# build/x86-64/%.o log/x86-64/%.log .deps/x86-64/%.d
symbols/x86-64/%.symbols: %.c ; true
# build/x86/%.o log/x86/%.log .deps/x86/%.d symbols/x86-64/%.symbols: %.c ;
true
# build/armel/%.o log/armel/%.log .deps/armel/%.d symbols/x86-64/%.symbols:
%.c ; true
main.o err.o: %.o=%.o %.log .%.deps %.symbols: %.c ; true
# same as this where all targets of one rulesare generated in a single step
(as if there is a
# % sign in there but $* must be the empty string)
# main.o main.log .main.deps main.symbols: main.c ; # err.o err.log
.err.deps err.symbols: err.c ; true
Please consider making each rule defined like this fail if any of the targets
for one factor is not updated unless it is a prerequisite of .PHONY to avoid
incorrect builds due to mistakes. ie, all non-phony targets must be updated by
its rule. I can imagine mistakes in the recipes for multiple simulataneous
outputs causing bad incrmental builds.
I will be happy to do the bulk of the work to implement this, if some guidance
can be provided and help with the hard bits.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?42125>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
