> Are you talking about autotools like `autoscan' and `autoconf', or the > generated ./configure itself? I was thinking about autotools and ./configure itself. For end user ./configure itself is more important (more ofen used). Each is dependent on many things, such as m4 and whatever /bin/sh > happens to point to. > > To make the tools truly friendly for SMP systems, they would have to be > re-written. The only (viable) library that I have seen thus far is from > Intel and remains proprietary. Ok, maybe turn ./configure more SMP will be easier? What about split ./configure to n files (n=2 for dualcore) ./configure ==> ./configure1 + ./configure2 and then /bin/sh ./configure1 & /bin/sh ./configure2 & or in ./configure odd commands run normally and even with & Autoconf / configure is quite forky and expensive, but is worth the > cost. I was checking my cores load, and the second one has a lot of idle, when ./configure goes. Regs, LLG _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
