Subject: Re: make(1) and .WAIT and .ORDER
From: David Laight <email@example.com>
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
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: firstname.lastname@example.org