In short: I think, no cache loading from manual explicite configure run (but for sub-packages and make-triggered), keeping it as it is. By this, if in doubt, by re-running all build tools, chances are best to get a correct result. Performance tuning for the price of correctness isn't always a good trade-off I think. Just in case I write about some experiences below. On Sun, Feb 6, 2011 at 11:11 PM, <Ralf.Wildenhues@xxxxxx> wrote: > Apparently, a lot of users do not even know about configure -C aka. > --config-cache which of course doesn't help Autoconf's reputation about > producing configure scripts which are slow even for development. I think the first question is: what feels slow? What is multi-platform-toolchain-language-single-srcdir-crosscompiling faster? For us often configure runs are triggered by increasing package version numbers, leading to updated config.h and to compiling everthing (probably this could be improved by using autoconf better?). Often caching system properties might be good for developers as long as remembering to clean the cache as soon as the system was updated. An automatism would be helpful, if possible. However, there is just one cache. We also use some code in configure.ac to get information about our own (sub-)packages. We have open issues where the cache renders this useless, because if a subpackage is updated it won't be detected. Hacks like touch configure.ac in Makefile failed, however behavior probably could be avoided by setting the cache variables in the "exporting" package I guess (would this be considered an implementation or a hack?). On cygwin, IMHO, configure -C slow. Make is slow, echo is slow, everything is slow... :) Caching IMHO really saves a lot of time here (but we use it for subpackages only). As we don't have much cygwin-specific code, in most cases we develop on linux. I don't know whether crosscompiling (build=linux, host=cygwin) is possible. Of course, the great thing about cygwin is that is usually works and "feels like a unix". Really cool. You can even select(2) serial ports. A great think about autoconf is that basically any needed exception may be added in configure.ac, could be the most strange thing (like "but do not use XYZ if cygwin version = 1.2.3 and expat is installed", having a special tool version installed or whatever). In the past we had issues with "stale" caches. MSYS seems to be much faster as cygwin, but more troublesome. I think it is nice to cross-compile with gcc-mingw on a linux box, test via WINE (BTW, can "make check" be made working? Recent linux distributions sometimes support starting .EXE files by automatically starting WINE). On linux when compiling native code, I only know about problems with stale caches about own (sub-)packages (which, as written above, probably are due to wrong usage of caching). On linux, when cross-compiling, we have all sorts of issues with "stale caches". Here most developers are used to manually re-run topdir/configure to get it clean. I think it would be unexpected that this would use some cache. It was called to configure, not to assume - in contrast to maybe a make-triggered configure, which might be supposed to be faster for the price of less correct. > So one question would be what about making -C the default? > We could have --force or --no-cache to turn it off. When a user runs "configure" I think no cache should be loaded. When configure runs subpkg/configure, I think a cache is good. When make runs configure, I think a cache is good, too. > Back then, the consensus was to not make it the default because that was > deemed too dangerous for users. I think this is still true (even more, because common linux users may read even less instructions than ten years ago). Here many developers don't care about the build process and they also don't use a "persistent cache" (in constrast to "subpackge-caching", which is used). So even developers don't use "make distclean". oki, Steffen _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
