>> I suspect that it might not even *work* to try to do a single
>> unified make run for the whole source tree - unless make gets a
>> great deal more efficient in both time and memory.
> on the other hand, forking a subshell and make for every directory
> isn't memory efficient either.

It is in some respects, actually.

It reduces swap thrashing, since the higher-directory makes can stay
swapped out in toto for long periods while the deeper makes run -
basically, it's an indirect way of marking some of the data as "won't
be needed for a long time", and keeping it partitioned from the stuff
that's in live use.

Also, it's possible to have multiple processes whose memory images adds
up to more than a single process can support.  (I don't know whether
this is relevant here, but it potentially might be.)

> would a 24MB decstation 3100 (16MHz R2000) be a suitably restricted
> target platform for demonstrating this?

My guess would be "yes".  (It's definitely a decent first cut. :)

> and the low memory slow machines is a testcase I wasn't thinking
> about, since the context has been parallel builds, which tend not to
> be so RAM crunched as other platforms.

True.  I've done builds on machines where the entire tree - source,
tools, and built binaries - could all fit in RAM.  When you have that
kind of resources available, a multitude of sins can be ignored.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B