In article <199511062341.PAA00768@antie.nas.nasa.gov> thorpej@nas.nasa.gov writes:
>
>>Number:         1734
>>Category:       bin
>>Synopsis:       New parallel make behaves incorrectly and non-intuitively.
>>Confidential:   no
>>Severity:       critical
>>Priority:       high
>>Responsible:    bin-bug-people (Utility Bug People)
>>State:          open
>>Class:          sw-bug
>>Submitter-Id:   net
>>Arrival-Date:   Mon Nov  6 18:50:01 1995
>>Last-Modified:
>>Originator:     Jason Thorpe
>>Organization:
>Numerical Aerodynamic Simulation Project - NASA Ames
>>Release:        NetBSD 1.0A, of Nov 5, 1995
>>Environment:
>	
>System: NetBSD antie 1.0A NetBSD 1.0A (ANTIE) #377: Mon Nov 6 11:56:55 PST 1995 thorpej@antie:/work/netbsd/src/sys/arch/i386/compile/ANTIE i386
>
>
>>Description:
>	The new parallel make behaves in ways that are at best non-intuitive
>	and at worst incorrect.
>
>>How-To-Repeat:
>	Go to the top of a NetBSD source tree, fresh, with no obj
>	directories, depend files, or objects.  Type the following command:
>
>	% make -j 4 obj depend all
>
>	Watch as .depend files and objects are sometimes created before
>	the obj directories and other such weirdness.
>
>	Alternatively, go to your kernel build directory.  Type:
>
>	% make clean depend all
>
>	Watch as new objects begin to appear before the clean is finished.
>
>>Fix:
>	Make should process targets on the command line in order, regardless
>	of whether or not it is operating in parallel mode.  Additionally,
>	it is arguable that when the `-j N' option is not used, make should
>	behave in it's traditional manner.  I.e., the following:
>
>	foo: bar zap
>
>	should be processed in that order _without_ requiring the additional
>	dependency:
>
>	zap: bar
>
>	If nothing else, this provides a measure of sanity for those
>	packages external to NetBSD which are not expecting this
>	non-intuitive and incorrect behavior.
>>Audit-Trail:
>>Unformatted:

I don't have the answer to that...

Consider:

foo: foo.o bar.o baz.o
	cc -o ...


Now if what you are saying is to be done, then the parallel make should make
first foo.o wait for that to finish, then bar.o wait for that to finish,
and then finally baz.o... Well, there is not much parallelism in there is
there?

The -B flag [be backwards compatible], tries to do that by executing
things in order.

I don't know what is the best solution to solve the problem you are describing.
I've been using pmake for many years now, and I've seen the broken behavior
you mention. Most Makefiles do work correcly without -B though [I would say
close to 95% of the Makefiles that one tries]

    make -j 4 obj && make -j 4 depend && make -j 4 all

works like you expect it. 

Maybe the default -j 1 should imply -B?

Note that I did explain all that in detail when I committed the changes...

christos