[ccache] Configuration file plan
joel at rosdahl.net
Wed Apr 27 13:56:04 MDT 2011
On 2011-04-07 03:17, Wilson Snyder wrote:
> A read of a NFS file can cost 100 msec, which adds up across thousands
> of compiles. Reading /etc is fine, but in our setup HOME is slow.
> [...] So I'd suggest CCACHE_CONFIG_PATH which could be a colon
> separated list of directories to search, defaulting to say
> "/etc:$HOME/.ccache". I could then simplify it to "/local_ssd/ccache"
> for my site.
Actually, I've already thought about the "slow $HOME" case, but I forgot
to describe it in the mail. :-) To avoid reading $HOME/.ccache, I'm
thinking it should be enough to put "cache_dir = /local/ssd/ccache" in
/etc/ccache.conf. configuration reading will be done something like
1. Populate a configuration struct with compile-time defaults (e.g.
"cache_dir = $HOME/.ccache").
2. Update the struct with settings from <sysconfdir>/ccache.conf.
3. Update cache_dir in the struct from the CCACHE_DIR environment
4. Update the struct with settings from ccache.conf in cache_dir.
5. Update the struct with settings from other CCACHE_* environment
Do you think this will be good enough?
> [...] Also, I'd really like to have a hierarchy as I cache stuff on
> network-closer systems. [...] This would also allow creating a
> compile-directory local file of ".ccache" which would be awesome for
> some uses, and for testing.
I guess you're talking about having multiple cache directories so that
you can read cache results from (or even write to) several places? That
would also be interesting to mock up, but that's not what I'm currently
trying to design.
> I suspect what you're aiming for is an INI file format. INI files are
> a non-standard standard :) so I'd suggest copying git's. See below.
I think git's configuration format is a bit overkill for ccache, and its
configuration parsing code also isn't generic enough to steal.
> Can -p print the output in .ini format? That way people can easily
> convert an existing env var setup to .ini format!
My idea was that it should print the current settings and from where
each setting originates, but that's maybe overkill. But it could very
well print it in ".ini format", yes.
>> The -F and -M command-line options will update the configuration file
>> instead of the stats file (and those entries in the stats files will
>> become obsolete).
> What if there's no file or more than one? Seems to me it's much safter
> to punt.
As said above, there will still be one and only one cache directory, so
a configuration file will always be available (unless it's read-only, of
> In general I don't like programs rewriting config files
I agree. I would be nice to be able drop the -F/-M options (and my
suggested -o option) but I'm not sure about how much breakage that would
cause. Perhaps it's best to just deprecate them and let them emit
> Also, rather than add any new env vars, I'd suggest a CCACHE_FLAGS
> which can contain arguments to the program, then people can just use
> CCACHE_FLAGS="-o goo=bar" rather than your adding CCACHE_GOO.
More information about the ccache