Follow-up Comment #7, bug #27609 (project make):
Also, another consideration is that the prerequisite .y is involved in an
explicit rule. If an implicit rule matches some file as a prerequisite, but
that file is already used as a prerequisite in some rule, then those rules are
competing. Maybe make should assume that the explicit rule takes precedence.
I'm not so confident about this because there are situations where something
is a prerequisite to more than one rule. (Like the obvious case of a header
file being a dependency for many objects).
Nevertheless, there are situations where prerequisites are typically
understood to be processed by just one rule. You probably would not want to
pass a .y file through yacc twice in two different rules. If such a situation
exists, and one of the rules is generated from an implicit template, but the
other one is explicit, somehow the explicit one should win.
Or some syntax could denote ``weak'' rules.
You know how there are order-only prerequisites; there could be a similar
extension to denote weak-exclusive prerequisites, and another extension to
denote clobbers.
For the sake of concrete discussion, let's use the characters @ and & for
clobbers and exclusive prerequisites. The rule could then look like:
%.c: & %.y @ y.tab.c
$(YACC) ...
mv ...
So now, if the rule matches some ``foo'' stem, we have a target foo.c, a
exclusive prerequisite foo.y, and a clobber y.tab.c.
The exclusive prerequisite tells make that this rule must be exclusive for
that prerequisite. If two explicit rules are exlusive for the same
prerequisite, then the situation is erroneous: a diagnostic is emitted and the
make fails. If the exclusivity conflict is between an implicit and explicit
rule (like the above case), then the implicit rule is treated as weak: it is
resolved in favor of the explicit rule.
The clobber element y.tab.c informs make that the rule body destroys the file
y.tab.c, which is neither a target nor prerequisite. Make will suppress this
rule if y.tab.c appears as a target or prerequisite in any other rule
(possibly with some warning diagnostic?). Moreover, if two or more rules both
specify y.tab.c as a clobber, the execution of those rules will be serialized
(in either order, just not parallel).
Note that this allows phony clobber files to be used as mutexes for
serializing rules, which could be handy! Suppose that two rules exist which,
say, do something destructive in the same CVS sandbox (like an update) which
can modify the CVS/Entries and whatnot. They could have a clobber called
``cvs-mutex'', and make would thus not run those rules in parallel. This may
be easier than inserting fake dependencies to enforce an order. I know there
is .NOTPARALLEL, but that's a big hammer.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?27609>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
