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

-- 
David Laight: david@l8s.co.uk