On Tue, 8 Feb 2011, Marian Marinov wrote:
Hello guys, After Ralf's talk at FOSDEM I'm really enthusiastic about autoconf paralization.
There are quite a lot of things to address before something exotic like parallelization is considered.
For one, configure usually chooses the slowest shell on the system. This happens to be a very popular GNU one. It would be useful for that shell to run much faster, or for configure to work well with a shell which runs much faster.
If we can agree on minimal functionality required from the shell, then configure can be streamlined to run faster.
The configure script is still many times too large. Configure scripts should not be 1MB (or more) in size. Configure scripts seem to explode the scriptage by 10X what the user specified. This is not necessary since common-bits can be versioned and formally installed. Devising ways to make the configure script smaller should help make the configure script run faster.
The actual tests which are performed (run compiler, linker, etc.) seem like they are only a fraction of the total time expended.
Lastly, a special "shell" designed to run only configure scripts would be quite useful since it could be very small, embeddable, and include extensions specifically for use by configure scripts. For example, some of these extensions could implement autoconf intrinsics.
Extensible light-weight shells like 'rc' and 'es' (http://en.wikipedia.org/wiki/Es_shell) can serve as an example.
It takes about 1/4 of a second for 'autoconf' to produce a 1MB 'configure' script for my project. We should be seeing execution performance more like that (with consideration for running external build tools) from configure.
Bob -- Bob Friesenhahn bfriesen@xxxxxxxxxxxxxxxxxxx, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
