[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Parallel Make
Re: Parallel Make
Thu, 01 Apr 2004 10:52:53 -0500
Mozilla Thunderbird 0.5 (Windows/20040212)
I'm not convinced that build systems would break if -j without arguments
suddenly meant nothing instead of infinitely parallel. The build would
run serially but it would proceed correctly. In my environment -j
without arguments is invariably not what we want so if this doesn't get
changed in gmake itself, I will end up patching it locally anyway. I
just hoped that others saw this as a flaw with -j and that it would be
easy enough to fix.
However, that part of the discussion was an aside and my real concern is
that I was actually giving an argument to -j which was ignored. It is
not always ignored but in 10 builds it was ignored 5 times. When "-j 4"
is the first argument on the command line it never happens. When it
appears after a variable assignment it happens occasionally. Any ideas?
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
why not throw non-blocking behavior on as default and add a O_BLOCK flag
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
My casual too sence ;-)