jimbo@ssd.harris.com (Jim Winters) (08/09/89)
Hi. I think there's a bug in GNU make version 3.27. I tried to use GNU make because I wanted to use the "-j" option, but the problem was that it didn't run the jobs concurrently. I looked into this in the source a little. Make is picking up the "-j" option fine, but it later resets the value to "1". It looks like make is creating a MAKEFLAGS variable in construct_makeflags, and is then reading that variable as though it were originally in the environment. construct_makeflags always sets the "-j" option to 1 (I assume that's to avoid an explosion of processes). I didn't understand enough of what was going on in the code to know why make processes the variables this way. I don't really think it makes any difference what makefile you use, but here's a teeny one that demonstrates the problem: ----- a: sleep 5;echo toot sleep 5;echo toot ----- Thanks for your attention to this.
montnaro@sprite.crd.ge.com (Skip Montanaro) (08/11/89)
In article <8908082032.AA03081@SSD.HARRIS.COM> jimbo@ssd.harris.com (Jim Winters) writes:
I tried to use GNU make because I wanted to use the "-j" option, but
the problem was that it didn't run the jobs concurrently.
...
I don't really think it makes any difference what makefile you use,
but here's a teeny one that demonstrates the problem:
a:
sleep 5;echo toot
sleep 5;echo toot
There is no bug that I know of with the -j flag. Your example Makefile has
only a single target, so there are no multiple targets to possibly build in
parallel. Make can't infer that the two commands necessary to update target
'a' are independent. Try this example instead:
a : a.o b.o c.o
cc -o a a.o b.o c.o
a.o : a.c
sleep 5; cc -c a.c
b.o : b.c
sleep 5; cc -c b.c
c.o : c.c
sleep 5; cc -c c.c
"gmake -jn" (n >= 3) correctly compiles all three C source files in
parallel. It can tell there are no side effects because of the target/source
dependencies. We've put the -j flag to good use on our Convex and our
Stellar, even though we've only been using GNU make for a short time.
--
Skip Montanaro (montanaro@sprite.crd.ge.com)