[ccache] Why not cache compile failures?
shentino at gmail.com
Wed Oct 3 18:10:37 MDT 2012
On Sat, Sep 29, 2012 at 6:23 PM, Martin Pool <mbp at sourcefrog.net> wrote:
> I think caching errors would be worth trying. It may help with
> configure, and it may also help with people rebuilding trees that from
> time to time have errors in them.
> Depending on the compiler, it may be possible to see from the
> waitstatus that it was interrupted, and so to avoid caching the
> result. Or, perhaps you can do something with process groups to let
> ccache observe the interrupt signal itself and so be sure not to cache
> If you emit a message when printing a cached error it ought to be safe
> enough to experiment with.
> On 29 September 2012 20:07, Shentino <shentino at gmail.com> wrote:
>> I'd have to agree that caching failures is tricky.
>> Transient errors are temporary by definition and shouldn't be cached.
>> What if compile failures were only cached for a limited amount of
>> time, say, an hour or so?
> I suppose you are proposing this because you think the cache will
> often be wrong,
Not really. I did mean to add "TTL" as an attribute to cache entries
for compile failures, not for compile successes.
It's rather a strange assumption to make about my reasons for suggesting it.
Call it (optional?) insurance against a transient failure being cached.
> and limiting the TTL will limit the damage. But, if
> the cache is unreliable, adding in an additional time-based factor
> will make things worse: suppose someone is trying to debug it and
> things suddenly start working again?
More like failures are inherently trickier to cache because of them
being more apt to be transient. A success is rather solid.
It wouldn't be a small step to imagine the TTL being ignorable for
debugging purposes or for whatever other reason.
> As much as possible we want things to be pure functions of the input,
> both in the input to ccache, and in how ccache itself behaves.
True enough, and I agree wiht that. My suggestion was more how to deal
with external interference from transient conditions that likely have
nothing to do with said input.
The other comment regarding having ccache test for "nuisance" signals
like SIGINT and/or looking for memory or filespace shortage errors
would probably help weed out transient failures before they are
considered eligible for caching.
> The vast majority of errors are due to actual errors in the source
> code in the context of the environment and flags.
Including configure scripts testing for features, which would make it
worthwile to consider how to cache them without mopping up transient
failures caused by things such as resource constraints.
> If the compiler is
> intermittently giving errors for other reasons, the user really needs
> to stabilize them before thinking about using ccache.
I agree mostly but it would seem wise to be robust against surprises
that the user cannot predict, hopefully without tainting the cache in
> ccache mailing list
> ccache at lists.samba.org
More information about the ccache