help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improvement on parallel make


From: Paul Smith
Subject: Re: Improvement on parallel make
Date: Mon, 11 Dec 2006 19:50:26 -0500

Hi all;

This thread is very interesting and I'm saving all the emails for a more
careful study.

However, can I request that everyone REMOVE the address@hidden
address from the thread?  That list doesn't exist; it's just an alias
for address@hidden  You can use either one, but if you use both then
I (at least) get two copies of every mail, which is mildly annoying.
Thanks!

On Mon, 2006-12-11 at 18:12 +0000, Brendan Heading wrote:

> > I'm also unimpressed by the fact that the cited examples all seem to
> > use .WAIT as a kludge around the incomplete dependency tree of a
> > recursive make setup.  Making that particular hole easier to live in
> > just means more people will dig themselves into it...
> 
> I was waiting for someone to say this. 

This has been discussed just about every time this enhancement is
requested :).

It is theoretically POSSIBLE to do as you say, especially with the
advent of order-only prerequisites.

But it is sometimes very, very messy and difficult.

The problem is that while you can easily declare a dependency
relationship between two targets, that relationship does not extend to
their prerequisites, and so on down the line.  If you want it to, you
have to declare that same dependency relationship for all those
prerequisites.

For some examples of what I mean, see this thread:

http://www.mail-archive.com/address@hidden/msg05599.html

These aren't "real world" examples, but they illustrate the problem.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




reply via email to

[Prev in Thread] Current Thread [Next in Thread]