[ccache] Configuration file plan
wsnyder at wsnyder.org
Wed Apr 6 19:17:29 MDT 2011
>I would like to improve ccache's configurability. As you
>know, configuration of ccache is today done by setting a
>bunch of environment variables, but that's becoming
>increasingly messy; there are currently 24 CCACHE_*
>variables in the development version of ccache. I think
>it's time to move settings to a configuration file while
>keeping the ability to override configuration by setting
This sounds great!
>I actually envision two configuration files:
>- <sysconfdir>/ccache.conf (typically /etc/ccache.conf)
>- <ccachedir>/ccache.conf (typically $HOME/.ccache/ccache.conf)
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. Also, I'd really like to have a
hierarchy as I cache stuff on network-closer systems. 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.
This would also allow creating a compile-directory local
file of ".ccache" which would be awesome for some uses, and
>I expect that the overhead of reading the configuration
>file(s) will be negligible.
Not really - see above.
>The "max files" and "max size" settings (set by
>command-line options -F/--max-files and -M/--max-size) are
>today stored in the "stats" files in the cache, but these
>will find a much better place in <ccachedir>/ccache.conf.
Getting these out of the cache would be great. Every few
months someone resets our cache without using our special
create script, and we loose the -F/-M's.
>I think the configuration file syntax should be a simple
>text format like this:
> # A comment.
> key = value
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.
> -p, --print-config print current configuration settings
Can -p print the output in .ini format? That way people can
easily convert an existing env var setup to .ini format!
>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. In general I don't like programs
rewriting config files, and I really don't want users
mucking with the config. (Actually I'd probably have the
config file under version control and thus read only so it's
safe - please be sure the error message is nice if a -F
fails due to a non-writable file.)
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.
=== from git-config
The syntax is fairly flexible and permissive; whitespaces are mostly
ignored. The # and ; characters begin comments to the end of line,
blank lines are ignored.
The file consists of sections and variables. A section begins with the
name of the section in square brackets and continues until the next
section begins. Section names are not case sensitive. Only alphanumeric
characters, - and . are allowed in section names. Each variable must
belong to some section, which means that there must be section header
before first setting of a variable.
All the other lines are recognized as setting variables, in the form
name = value. If there is no equal sign on the line, the entire line is
taken as name and the variable is recognized as boolean "true". The
variable names are case-insensitive and only alphanumeric characters
and - are allowed. There can be more than one value for a given
variable; we say then that variable is multivalued.
Leading and trailing whitespace in a variable value is discarded.
Internal whitespace within a variable value is retained verbatim.
The values following the equals sign in variable assign are all either
a string, an integer, or a boolean. Boolean values may be given as
yes/no, 0/1 or true/false. Case is not significant in boolean values,
when converting value to the canonical form using --bool type
specifier; git-config will ensure that the output is "true" or "false".
String values may be entirely or partially enclosed in double quotes.
You need to enclose variable value in double quotes if you want to
preserve leading or trailing whitespace, or if variable value contains
beginning of comment characters (if it contains # or ;). Double quote "
and backslash \ characters in variable value must be escaped: use \"
for " and \\ for \.
The following escape sequences (beside \" and \\) are recognized: \n
for newline character (NL), \t for horizontal tabulation (HT, TAB) and
\b for backspace (BS). No other char escape sequence, nor octal char
sequences are valid.
Variable value ending in a \ is continued on the next line in the
customary UNIX fashion.
Some variables may require special value format.
# Core variables
; Don´t trust file modes
filemode = false
# Our diff algorithm
external = /usr/local/bin/diff-wrapper
renames = true
remote = origin
merge = refs/heads/devel
# Proxy settings
gitProxy="ssh" for "kernel.org"
gitProxy=default-proxy ; for the rest
More information about the ccache