Re: Static multiple target rules

[tom honermann]

On 3/30/2010 11:35 PM, tom honermann wrote:

On 3/29/2010 8:20 PM, Philip Guenther wrote:

Hmm.  SysV make has offered the desired feature with the syntax

b1 + b2 + b3: d1
        touch -r $^ $@
 

Ah, thank you!  I wasn't aware of a precedent syntax for this feature.  I definitely agree with
using this syntax over what I proposed for compatibility with sysV and (potentially) future
POSIX standardization if the sysV semantics are adequate.  I'll run some tests with the
Solaris 10 version and follow up with comparisons with the semantics I had proposed.

I adapted my prior example for the sysV group target syntax and did some testing with
the Solaris 10 make implementation:

all: y.tab.h y.tab.c y.output y.tab.o

clean:
        rm -f y.tab.h y.tab.c y.output y.tab.o

grammar.y:
        @touch $@

y.tab.h + y.tab.c + y.output: grammar.y
        @echo "Running yacc..."
        @sleep 1
        @touch y.tab.h y.tab.c y.output

y.tab.o: y.tab.c y.tab.h
        @echo "Compiling y.tab.c..."
        @sleep 1
        @touch $@

This worked as expected and I wasn't able to trigger any undesirable behavior.  Solaris
make seems to delay or recheck time stamps such that the following steps will cause
y.tab.o to be rebuilt.  Note that only y.output is out of date when the last make invocation
is made, but make recognizes that y.tab.h and/or y.tab.c has been rebuilt and therefore
regenerates y.tab.o as well.  Exactly what is desired.

$ make
$ touch grammar.y
$ touch y.tab.h y.tab.c
$ touch y.tab.o
$ make
Running yacc...
Compiling y.tab.c...

I went on to evaluate some other behaviors using this example:

Makefile:

all: a1 a2 a3

clean:
        rm -f a1 a2 a3

d1:
        @touch $@

a1 + a2 + a3: d1
        @echo "  \$$@:    >$@<"
        @echo "  \$$%:    >$%<"
        @echo "  \$$(@D): >$(@D)<"
        @echo "  \$$(@F): >$(@F)<"
        @touch -r d1 $@

$ make clean
rm -f a1 a2 a3
$ make
  $@:    >a1<
  $%:    ><
  $(@D): >.<
  $(@F): >a1<

Note that $@ expanded to the first requested target (from the default 'all' rule).
Separate commands were not run for targets a2 and a3.  Had the targets been
normal targets instead of group targets, the commands would have been run
three times each to generate a1, a2, and a3.

$ make
  $@:    >a2<
  $%:    ><
  $(@D): >.<
  $(@F): >a2<

Note that 'make clean' was not run here.  The commands above did not
generate a2 during the first make invocation.  Make now notices this and
invokes the rule to build a2.

$ make
  $@:    >a3<
  $%:    ><
  $(@D): >.<
  $(@F): >a3<

Same thing again.  Now we're all up to date.

Solaris make allows group members to be phony targets, but there are caveats.  The
example above shows that the implementation doesn't check to make sure all group
members were actually generated (which is good and consistent with normal phony
target rules).  However, here are is an example showing behavior which I find
somewhat baffling:

all: b1 b2

clean:
        rm -f b1 b2

b1 + b2: d1
        @echo "  \$$@:    >$@<"
        touch b1

Consider the following output:

$ make clean
rm -f b1 b2
$ make b1 b2
  $@:    >b1<
touch b1
`b2' is updated.

b1 was requested first.  b2, though not generated, is considered up to date.

$ make clean
rm -f b1 b2
$ make b2 b1
  $@:    >b2<
touch b1
  $@:    >b1<
touch b1

In this case, b2 was requested first and the rules run.  However, Solaris make then
ran the rules again to generate b1.  I would have expected it to consider b1 up to
date once b2 was built.  The implementation apparently checks to see if the
requested target was actually completed and only considers the group up to date
if it was.

Solaris make (at least Solaris 10) does support multiple group targets.  For an
example, see my most recent email to the mail list.

Solaris make does support archive members as target group members as well.

Solaris make has support for the .IGNORE and .SILENT special targets
however, prerequisites for these are only supported when the special .POSIX
target is also specified.  When running commands for a target group member,
the current target is used to determine whether the .IGNORE or .SILENT
behavior is in effect.  For example:

all: i1 i2
all: s1 s2

clean:
    rm -f i1 i2 s1 s2

.POSIX:
.IGNORE: i2
i1 + i2: d1
        @echo "  \$$@:    >$@<"
        touch i1 i2
        exit 1

.SILENT: s2
s1 + s2: d1
        @echo "  \$$@:    >$@<"
        touch s1 s2

In the following example runs, the current target is always the first one specified
on the command line.

$ make clean
rm -f i1 i2 s1 s2
$ make i1 i2
  $@:    >i1<
touch i1 i2
exit 1
*** Error code 1
make: Fatal error: Command failed for target `i1'

$ make clean
rm -f i1 i2 s1 s2
$ make i2 i1
  $@:    >i2<
touch i1 i2
exit 1
*** Error code 1 (ignored)
`i1' is updated.

Note that the error was not ignored when the 1st target was i1, but the error was
ignored when the 1st target was i2.

$ make clean
rm -f i1 i2 s1 s2
$ make s1 s2
  $@:    >s1<
touch s1 s2
exit 0
`s2' is updated.

$ make clean
rm -f i1 i2 s1 s2
$ make s2 s1
  $@:    >s2<
`s1' is updated.

Note that commands were echoed when the 1st target was s1, but were not when
the 1st target was s2.

The differences in the Solaris make implementation vs what I had proposed include:

1: Obvious syntax differences.  The Solaris syntax prohibits nested groups which
is likely a good thing.

2: I had proposed that $@ and $% expand to include a list of all the target group
members.  Solaris make expands these to only include the current target.  For
compatibility, it makes the most sense to follow the Solaris model.  Additional
variables could be introduced that expand to the list of all targets (ie, $(@^)) or
archive members (ie, $(%^)) and perhaps another set of variables that expands
to the list of targets that are out of date (ie, $(@?) and $(%?)).  Combinations
for selecting directory and file parts would be possible as well: $(@^D) and
$(@^F) for example.

3: I had offered three possibilities for handling special targets that could have
conflicting settings across group members.  The Solaris make implementation
uses the third possibility I mentioned - using the attributes associated with the
current target (the group member first requested).  This makes sense to me.

All in all, the Solaris make implementation makes sense to me and would fit my
needs.  The only part about it that I feel concern about is how it handles phony
target group members.  But, there may not be good use cases for phony members.
I couldn't find any documentation addressing this for the Solaris make
implementation.

Tom.