Even those Autoconf users who are aware of -C do not like the slowness of configure and the amount of tests that some projects use. Since we still lack some ideas for an efficient parallelization, we should maybe think about ways to speed up things for those users that build lots of packages, once, in a fairly similar environment. For example distro builders. Some random ideas gathered: Distributions could ship with a config.site base file for the base system which could contain information about the header files installed, the base types, and so on. Packages could then build upon that and add more information about now-installed header and library files. The default config.site file could look into a special directory and source some or all per-package site files in there, to gather all this information on the fly (and maybe even do some basic consistency checking?). One big question is whether the creation of such data could be done automatically. It is not likely to succeed if every package author or distro package maintainer has to invest much more work than invoking some script or package build hook, to do this extraction. Of course another question is whether such data can be generated safely at all. For example, header file existence is pretty safe, but whether the preprocessor actually accepts the header might even depend on whether some third-party header file is or is not installed. Related question would be to just assume that, if the dependency information in a distro package data base is correct, then these kind of issues cannot happen behind our backs. Autoconf could provide some kind of functionality to determine whether some cache variable is safe to keep. For simplicity, we probably need to limit using such site files to configure invocations without special CC, CFLAGS etc. settings. Comments and suggestions appreciated. Thanks, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
