Subject: Re: make(1) and .WAIT and .ORDER
To: <>
From: David Laight <>
List: tech-userlevel
Date: 11/14/2006 07:57:37
On Tue, Nov 14, 2006 at 12:37:32AM +0200, Alan Barrett wrote:
> > 
> > This has the side effect that:
> >     a: b
> >     .ORDER b a
> > is a deadlock - which might not, at first glance, be invalid syntax.
> It would be nice it this worked.  Does your version still give each node
> a list of ancestors?  If so, then when 'a' gets to the front of the work
> list, and we notice that it has 'b' as an un-made .ORDER predecessor,
> we could immediately check whether 'a' is an ancestor of 'b', and if so
> then don't let the presence of the .ORDER cause a deadlock.

Generating a full list of ancestors is one of the things that can get
(almost) unbounded.

If it is a real problem, doing something to break the deadlock once the
make has run out of targets it can build - but the required targets
aren't built yet - might be possible.

Also a non-recursive .ORDER could be implemented, but I don't think
it should be the default. (It can be done using an extra .PHONY target).

I've also realisized that:
    .ORDER a b c
has to be expanded to:
    .ORDER a b
    .ORDER b c
    .ORDER a c
The 3rd entry is needed when 'a' and 'c' are to bu built, but 'b' isn't.


David Laight: