help-make
[Top][All Lists]
Advanced

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

Re: Parallel Make


From: Noel Yap
Subject: Re: Parallel Make
Date: Thu, 01 Apr 2004 10:00:29 -0500
User-agent: Mozilla Thunderbird 0.5 (Windows/20040212)

Tristan Van Berkom wrote:

Noel Yap wrote:

I agree that a lone -j shouldn't default to infinity for practical reasons. OTOH, a default of 1 would make the flag meaningless and a default of 2 seems unclean to me. IMHO, -j shouldn't have a default at all. Further, for those that like the infinite behaviour, I think allowing --jobs=infinity would help curb such an appetite a little.

    Hmmm, the same could be said about the unix open system call; why
should i have to open a named pipe in read/write if I dont want to block ?
why not throw non-blocking behavior on as default and add a O_BLOCK flag
instead ?

Ok, so its a bad example; but what I'm getting at is that you cant just
modify the expected behavior of the open() system call because everyone's
code will instantly break, much in the same way as IMO, many build
systems will break when you change the expected behavior of GNU make.

If everyone is bent on changing that behavior, why not add something new
like `-J' which behaves exactly like `-j' but with a different default
behavior ?

To satisfy parsimony, I can understand why a default of infinity would be good. 
 OTOH, the issue here is that having an interface that makes a dangerous 
behaviour easy to invoke isn't good.

I would suspect that those using the default is in the minority.  They'll be 
the ones satisfying at least one of the below:
- not understanding the consequences of launching a large number of jobs.  
These developers will soon learn not to do this.
- working on small projects, but then, why use -j at all?
- using --max-load.  These developers can start using the proposed 
--jobs=infinity if they want to keep doing this.

For a small, stable group of developers, it's easy to say the developers should learn how to use the tool correctly. When the number of developers grows, though, and these developers share a common set of compile servers, chances are, there's /always/ someone who needs to be educated so "educate them" will be much easier to follow if poor behaviour wasn't the default.

Noel





reply via email to

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