Sun 17 Apr 2016 03:33:24 PM UTC, comment #2:
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.
|