Re: Proposed syntax for coincidental rules

[Alessandro Vesely]

Paul D. Smith wrote:
> The purpose of having multiple targets in explicit rules (today) is a
> kind of syntactic sugar that allows you to condense a number of rules
> that are identical except for the target name, into one declaration.
>
> In other words, this:
>
>     foo bar baz: blah
>             cp $< $@
>
> is exactly identical to this:
>
>     foo: blah
>             cp $< $@
>     bar: blah
>             cp $< $@
>     baz: blah
>             cp $< $@
Assuming that parallel build is the only "bad thing" that make would do
in case of coincidental targets, then for a makefile like

.COINCIDENTAL: foo bar baz
foo: blah
        cat blah | tee foo | tee bar > baz
bar: blah
        cat blah | tee foo | tee bar > baz
baz: blah
        cat blah | tee foo | tee bar > baz

it would be enough to avoid that any two or more coincidental targets
are build in parallel. In case I have another set of coincidental
targets, e.g.,

.COINCIDENTAL: x y z

a smart implementation can still build, say, foo and x in parallel.
A minimal implementation might just switch off -j altogether. A
medium support could consist in reserving one and only one process
for all coincidental targets. The latter has the advantage of not
forcing the user/writer to have a precise knowledge of how coincidental
targets are partitioned into subsets.

> My problem with something like .COINCIDENTAL is that it doesn't enforce
> a locality of reference.  That is, the set of targets can be defined in
> one place and .COINCIDENTAL can be somewhere completely different.  This
> can be extremely confusing and difficult to understand for both the
> makefile writer and the user.
Alternatively, a syntax like

foo bar baz: .COINCIDENTAL
x y z: .COINCIDENTAL

might look less confusing to a trained eye. It somehow resembles that
trick mentioned in previous posts, except that each occurrence of the
special target should be considered different despite reusing its name,
and that commands are given for the real targets at any rate.

Specifying commands for the real targets _is_ less confusing :-)

> Of course in some situations it's important to have the flexibility to
> define things "remotely".  But, I'm not sure this is one of those
> times.  Is there real benefit to this?
By "remotely" you mean in a different part of the makefile? If I want
a different behavior, I must ask for it somewhere. When I compile Java
programs I can compute the transitive closure for mutually dependent
files and thus partition the set of all targets in a fixed way. Using
variables for the subsets should result in quite compact makefiles.
However, for the "medium support" case above, it would be enough to
declare all %.class files as coincidental.

Finally, I heard about compiling multiple C sources and produce the
corresponding object files at once. I don't know how that scales w.r.t.
parallel builds, but since it's about efficiency some may want to
experiment mixing the two... It would be more consistent with make's
philosophy to introduce a fairly general concept rather than something
specifically aimed at Java.