On Sat, Sep 29, 2012 at 6:23 PM, Martin Pool <m...@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 > 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,
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 the process. > -- > Martin > _______________________________________________ > 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
