Am Fre, 2002-06-07 um 16.49 schrieb Bill Wendling: > Also sprach Akim Demaille: > } >>>>> "Steven" == Steven G Johnson <[EMAIL PROTECTED]> writes: > } > } >> They don't have understood the point. And then, why keep the .o > } >> too? And the .deps? > } > } Steven> Again, it's a matter of tradeoffs and optimizing for the > } Steven> common case. On the one hand, programs spewing files as a > } Steven> side-effect that the user didn't explicitly request is > } Steven> generally undesirable. On the other hand, developers change > } Steven> source code files and recompile *very* often, so the extra > } Steven> speed (which can be orders of magnitude for .o!) is worth the > } Steven> filesystem litter. > } > } By we just do agree here! autom4te.cache appears when autoconf, > } autoheader or automake is run. We are not talking about end-users here. > > So, to summarize the complaints, we had a cache file (config.cache) which > was useful to a small number of people but deemed "harmful" to the > majority because of various compelling arguments given on this list. You are missing an essential point:
* config.caches had been generated when installers ran "configure", ie. anybody (including "casual installers" and non-developers) who ran a configure-script saw them and potential was a victim of the side-effects of config.caches (The typical complaint of casual installers: "I reran configure after having installed "package x" configure had complained about, but it still claims "x" missing.) * autom4te.caches are generated when generating autoconf etc. generated files. This is something "casual installers" are supposed never to see happen and is supposed to work transparently for developers. => There are several magnitudes in between the number of persons who see and are not aware about use config.caches and those who see and are not or semi-aware about using autom4te.caches. > We now have a similar situation with the autom4te.cache directory. It's > useful only to a small number of people and an annoyance (read: not > harmful, but a nuisance) to the larger number of people. I have to reiterate: Casual installers will not see them and they are not supposed to be part of any source-tarball. Developers will see them, but the positive side-effects (speed up of regenerating auto* generated files) by far outweighs the negative side-effects [1]. The only problems I have with autom4te.caches are 1. To have them removed for distibution tarballs - make distclean doesn't remove autom4te.caches. - for packages where "make dist" does not work (which is valid for many non-trivial packages) you have to have to manually remove them. 2. The size of autom4te.caches (They blow up the size of one source-tree I am working at by factor 2 (160MB instead of 80MB)) 3. Using autom4te.caches is not backward compatible to older autoconf-versions. > By Steven's own reasoning, it should be disabled by default and given a > flag so that those who need it will have it. Ralf
