Re: cache directory is not removed

[Ralf Corsepius]

Am Fre, 2002-06-07 um 16.49 schrieb Bill Wendling:
> Also sprach Akim Demaille:
> } >>>>> "Steven" == Steven G Johnson <address@hidden> 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