> 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 _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
