On Thu, Feb 16, 2006 at 01:15:16AM -0500, der Mouse wrote:
> Based on my experience watching slow machines sit and think for long
> periods of time digesting the 1.4T libc Makefile, 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.  the .text sections of all those makes and
shells can be shared, but I imagine the overall memory footprint being
comparable between the two.  in the nonrecursive case you spend it all
at once rather than being scattered over the thousands of
instantiations.

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

> > but somehow doing a recursive make and parsing those files
> > individually and not correctly expressing inter-directory
> > dependencies is acceptable.
> 
> Acceptable, as in, it mostly works, instead of sitting and thinking
> for hours and then falling over for lack of memory?

that's what needs to be determined.  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.

> Yes, I call that acceptable - as in "acceptable compromise".  I'd
> rather have a system that builds suboptimally than a system that
> doesn't build.  And while I haven't actually tried it (though I gather
> you haven't either), I suspect those would be our choices.

yeah.  as they say, the proof is in the putting.  I need to try it.  I
have a 2x 50MHz sparc20 and a 2x 300MHz i386 I can do some parallelism
tests on, and decstations and old PCs to cover the slow low-memory
situations.

obviously this will take a lot of time... (:

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier@poofygoof.com
              "silly brewer, saaz are for pils!"  --  virt