Earnie Boyd wrote: > So now I run `configure -C' always. I use the cache files to > determine problem areas of my runtime libraries.
Bill Wendling wrote: > BTW, the removal of automatically generating a config.cache file by > default was a bad idea, in my opinion. We actually use that file quite a > bit. Generating config.cache by default caused recurrent problems with users who would inadvertantly use stale config.cache files. The configure script is intended for *users*, who by far outnumber developers and are far less capable of realizing what config.cache is doing. It doesn't make sense to optimize the uncommon case (the developers, who are perfectly capable of using -C or of modifying config.site to make it the default) at the expense of the common case (the users). Akim wrote: > They don't have understood the point. And then, why keep the .o too? > And the .deps? Again, it's a matter of tradeoffs and optimizing for the common case. On the one hand, programs spewing files as a side-effect that the user didn't explicitly request is generally undesirable. On the other hand, developers change source code files and recompile *very* often, so the extra speed (which can be orders of magnitude for .o!) is worth the filesystem litter. >I don't think you realize the impact of using the cache here. On the >file utils, on my machine, it means that running automake, autoconf >and autoheader is about 1min long. Remove the cache, it's three >minutes. Running autoconf + automake + autoheader is not a common operation for most developers (autoconf developers don't count!), and in such a context I would argue that one minute vs. three is not that significant. Of course, as with all tradeoffs, this is a matter of opinion, and the people who run autoconf are developers so they can more easily deal with whatever autoconf spews. Still, I think that we should remember that readers of this list are not necessarily representative of autoconf users. Steven
