After letting this percolate in my mind for a few weeks, I am now
feeling a little more strongly that inability to write to the stats file
should be a fatal error (it will get attention FAST, and so fixed
quickly), but that when the stats file is writable, then placing an
indication of the problem there is "not silent", so it would be
acceptable to document the failure in the stats and continue with a
regular compilation that is "otherwise silent". If other people check
"ccache -s" as often as I do, and the error indicator in that output is
at all eye-catching, they will know soon enough that there is a problem
to be addressed, and someone with adequate privileges will address it
"soon", while others (including perhaps people without the privileges to
fix the problem) are able to continue compiling and get successful
builds rather than failures.
If I were looking at "ccache -s" output and saw a line like:
Unable to write to $CCACHE_DIR/a/b/ - permission denied: 303
I would certainly know that I needed to fix the permissions on that
directory.
And with that scheme, I think we could avoid adding any new CCACHE
environment variables to control different failure handling options.
Thanks,
Frank
On 01/10/2012 02:45 PM, Frank Klotz wrote:
I agree that "tools should not fail silently", but the problem here is
the definition of "fail". And that definition is going to depend on
context.
Ccache is not a compiler, but a compiler wrapper whose purpose is to
keep the functionality of the compiler it wraps, but merely speed it
up. Under some conditions (e.g., a nightly build where performance is
nice, but successful compilation if possible is crucial), getting a
compilation failure because the wrapper couldn't do what it wants would
be undesirable. For this case, silently falling back to a non-ccache
compilation would AVOID a failure, by successfully doing the compile
despite wrapper issues.
Under other circumstances (e.g., a small interactive build), you would
WANT to know right away if there is some issue with the wrapper, so you
can fix it immediately and all subsequent builds do get the performance
improvement offered by the wrapper. So here silently falling back to a
non-ccache compilation would BE a failure.
I hate to say it, but I kinda think you need to add another environment
variable - CCACHE_FALLBACK - with at least two possible values: hard
fail and fallback (there may be other possibilities as well - say "email
f...@bar.com", which would say "mail details of the problem to foo, but
go ahead and compile the dang file already!" Not actually recommending
that, but ....)
Then users can decide for themselves (on a per-task basis if necessary)
whether they care more about getting a successful compile whatever that
takes, or about having all compiles be as fast as possible, even if the
tool has to fail to compile something it COULD have compiled, in order
to get attention on a problem with the tool as fast as possible.
Which simply moves your question back a step to "what should be the
DEFAULT behaviour for this?
My suggestion on that would be:
If you can write to the ccache stats file(s) (cases 3 and 4), add
an error indication there, and silently fall back to non-ccache
compile. If you cannot even write to the stats file (cases 1 and 2),
fail. Maybe add a further refinement depending on whether the compile
is done in an interactive shell or not - people might want their nightly
cronjobs to succeed even if slower than ideal, but interactive builds to
fail so they can solve the issue.
But I don't have a really strong feeling on any of these.
Thanks,
Frank
On 01/09/2012 01:34 PM, Joel Rosdahl wrote:
Hi,
I would like to get some feedback on what ccache users think ccache's
behavior should be when it fails to create files or directories in the
cache directory.
Here are some different cases to consider:
1. CCACHE_DIR is set to a directory that doesn't exist and can't be created.
2. CCACHE_DIR is set to a directory that exists but is unwritable.
3. CCACHE_DIR is set to a directory that exists, but one of the
subdirectories storing the cache data (e.g. $CCACHE_DIR/a/b) is
unwritable or not possible to create.
4. CCACHE_DIR is set to a directory that exists, but CCACHE_TEMPDIR
(defaults to $CCACHE_DIR/tmp for ccache 3 and $CCACHE_DIR for ccache
2) is unwritable or not possible to create.
Here's what happens with ccache 2.4:
1. Fatal error, non-zero exit code.
2. Silent failure, falling back to running the compiler.
3. Silent failure, falling back to running the compiler.
4. Silent failure, falling back to running the compiler.
ccache 3.0-3.1.6 (I think, haven't checked all versions):
1. Fatal error, non-zero exit code.
2. Fatal error, non-zero exit code.
3. Silent failure, falling back to running the compiler.
4. Silent failure, falling back to running the compiler.
ccache 3.1.7:
1. Fatal error, non-zero exit code.
2. Fatal error, non-zero exit code.
3. Fatal error, non-zero exit code.
4. Silent failure, falling back to running the compiler.
ccache has previously been more forgiving, so one might argue that
ccache 3.x more strict behavior is a regression from version 2.4 that
should be fixed. Also, one might argue that ccache should never fail
fatally so that case 1 should silently fall back to running the
compiler as well.
On the other hand, my general opinion is that tools should not fail
silently. As a ccache user, I would like to be informed if something
is badly configured, for instance if the cache directory is unwritable
by me, so that I get alerted that something is wrong.
What do you think?
-- Joel
_______________________________________________
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
_______________________________________________
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
_______________________________________________
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
