In article <[EMAIL PROTECTED]> you write: >On Mar 20, 2007, at 11:23 PM, Alexandre Oliva wrote: >> As for configure scripts... autoconf -j is long overdue ;-)
>Is that the option to compile autoconf stuff into fast running >efficient code? :-) >But seriously, I think we need to press autoconf into generating 100x >faster code 90% of the time. Maybe prebundling answers for the >common targets... Doesn't win all that much. Over in OpenBSD, we tried to speed up the build of various software by using a site cache for most of the system stuff. Makes some configure scripts go marginally faster, but you won't gain back more than about 5%. Due to autoconf design, there are lots of things you actually cannot cache, because they interact in weird ways, and are used in strange If you want to speed up autoconf, it needs to have some smarts about what's going on. Not a huge list of generated variables, but what those variables *mean*, semantically, and which value is linked to what configuration option. You would then be able to avoid recomputing a lot of things (and you would also probably be able to compress information a lot... when I look at the list of configured stuff, there are so many duplicates it's scary). Autoconf also needs an actual database of tests, so that people don't reinvent a square wheel all the time. This would also solve the second autoconf plague: it's not only slow as molasses, but it also `auto-detects' stuff when you don't want it to, which leads to hard to reproduce builds, unless you start with an empty machine every time (which has its own performance issue). Even if it has lots of shortcomings still (large pile of C++ code to compile first), I believe a replacement like cmake shows a lot of promise there... In my opinion, after spending years *fighting* configure issues in making programs compile correctly under OpenBSD, I believe the actual database of tests is the only thing worth saving in autoconf. I don't know what the actual `good design' would be, but I'm convinced using m4 as a lisp interpreter to generate shell scripts is a really bad idea.
