On Thu, 16 Feb 2006, der Mouse wrote:
> Thinking about this, I think I've realized the problem.  Well, part of
> it, anyway.
> 
> .WAIT specifies too much.  It can be used for three purposes, and it's
> not the right thing for two of them.
> 
> (1) It can be used to say "don't build B until A is built".  This is
>     better expressed as a normal dependency (though we need a variant
>     that is "recursive", that applies to not just B but everything
>     under B).

I will refer to the non-recursive variant of (1) as (1n), and to the
recursive variant as (1r).

> (2) It can be used to say "don't do A and B at the same time".
>     However, it also specifies which of the two to do first, which
>     shouldn't be specified unless it actually matters.
>
> (3) It can be used when you really do want to say "do A, wait for it to
>     complete, then do B" when A and B aren't targets to be built but
>     "command verbs" (the sort of target .PHONY was invented for).  An
>     example might be a target which does dependall, install, and
>     cleandir; something like
> 	rebuild: dependall .WAIT install .WAIT cleandir
>     really is the right way to do this.  (Dependencies are not; for
>     example, to implement this with dependneices, cleandir would have
>     to depend on install, which is totally wrong.)

I'd like to use .WAIT for (3), and I think that this is the most common
way that .WAIT is presently used (except that the present non-recursive
implementation makes it work badly for this purpose).

.WAIT might not be ideal for (1b) or (2), but a recursive implementation
of .WAIT will be adequate until something better comes along.

.WAIT should probably not be used for (1a), and in practice, I think
.WAIT is seldom used when a normal non-recursive dependency is required.

--apb (Alan Barrett)