Re: cache directory is not removed

[Bill Wendling]

Also sprach Ralf Corsepius:
} Am Fre, 2002-06-07 um 16.49 schrieb Bill Wendling:
} > } 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.)
} 
I'm not missing the point on this. It was a diversion, but doesn't take
away from the autom4te.cache argument. I understand why config.cache was
removed, I don't necessarily agree that it should have been (there could
have been other options to removing it), but that's beside the point.

} * 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.
} 
You are writing autoconf for me (the developer), right? This is what I'm
talking about. I'm not saying the end user cares about autoconf or even
which version of autoconf I'm using. I'm saying that *I* care. *I* care
that there's this ridiculously "H4X0r"-named directory laying around that
I just don't need and clutters up my CVS tree and I have to remove it
after every regeneration.

Orders of magnitude isn't the case here. If *your* end users (i.e., me
and other developers) don't like a feature you just added, there should
be some way to turn it off. No matter how small or large your user base
is.

} > 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].
} 
Did I say get rid of it? No. I said give me the option of turning it off.

-- 
|| Bill Wendling                        address@hidden
|| Coding Simian