Re: [Axiom-developer] Building Axiom twice

[root]

> No, that is untrue if you say "make -jN", aka parallel build, which
> build-improvements must support.

this is purely my opinion but i don't believe that parallel builds
of axiom will ever succeed. i'm willing to be proven wrong and would
find that proof a pleasant surprise.

in sub-optimal builds of axiom this would be extremely difficult.
as soon as you try to do optimization i can't figure out how to 
break the circles in parallel. and i firmly believe that all of
the optimization work inside the axiom build is very important.

axiom could be so much faster if we got the gcl_collectfn mechanism
fully re-implemented. the lisp type optimization code can eliminate
hundreds of intructions per function call and axiom lives and breathes
by function calling. however to fully take advantage of that you 
either need to do multiple passes or cache the type information
from previous builds. doing this in parallel makes my hair hurt.

parallel builds cause the make to go marginally faster but my 
feeling is that the time-to-build is not important for two reasons.

first, a properly done make tree need only rebuild changed files
and their dependent files. when builds used to take 3 weeks from
scratch i was able to build changes to the system in 1/2 hour or so
for small changes using the current makefile structure. that is the
whole reason to use make in the first place. otherwise it just makes
sense to have a linear script.

second, only developers care about build time. the end user should
never see it (or maybe see it once). i'd rather spend a whole day
doing a build and get a highly optimized algebra system than spend
1 hour and get a slow algebra system. and that's saying a lot because
all i ever do is build and rebuild the damn thing.

fast algebra is much more important than fast builds.

t