[bug #42125] Explicit rules do not support multiple targets

[Tristan Wibberley]

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/