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 this: 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 variable. 4. Update the struct with settings from ccache.conf in cache_dir. 5. Update the struct with settings from other CCACHE_* environment variables. 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 course). > 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 warnings? > 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. Yes, perhaps. -- Joel _______________________________________________ ccache mailing list email@example.com https://lists.samba.org/mailman/listinfo/ccache