On Thu, Nov 13, 2014 at 2:27 PM, Andrew Stubbs wrote:
> Probably there was a timestamp in a generated header somewhere.
Another similar issue might be if you embed the build ID (the git commit
ID) in some weird way, like e.g. midnight commander does, so that every
tiny git commit causes a tota
Hi,
I'm absolutely sure that the source code's modification times are not
included. I pretty often compile, modify a file, save it, compile, undo
the changes, save again, compile again -> it's grabbed from the cache.
Same should happen after a git revert something like that.
egmont
On Tue, Nov
s/complications/compilations/
On Sat, Oct 18, 2014 at 7:46 PM, Egmont Koblinger wrote:
> On Sat, Oct 18, 2014 at 7:23 PM, Paul Smith
> wrote:
>
>>
>> Can someone describe the ccache support for this? I wonder how it might
>> (or might not) interact with GNU m
On Sat, Oct 18, 2014 at 7:23 PM, Paul Smith wrote:
>
> Can someone describe the ccache support for this? I wonder how it might
> (or might not) interact with GNU make's method of determining whether
> there's a controlling TTY, in cases where make's output synchronization
> is enabled.
>
>
I'm r
Hi,
It's been an unusually long time since the last ccache release.
I've just upgraded to Ubuntu Utopic (beta) which ships gcc-4.9 with its
nice coloring support, and ccache-3.1.9 which is unable to leverage this
feature. Fedora 21 is about to ship these versions, too.
Coloring support has been
On Mon, Nov 15, 2004 at 06:25:49PM +1100, Martin Pool wrote:
> The other factor is whether the cache will grow to include a million
> files.
We're building a distribution using a build system completely created by us
and it intensively uses ccache. We have approx 1000 packages, including, of
cour
