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 it. 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 <shent...@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, 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? 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. The vast majority of errors are due to actual errors in the source code in the context of the environment and flags. If the compiler is intermittently giving errors for other reasons, the user really needs to stabilize them before thinking about using ccache. -- Martin _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache