On 2011-02-28 13:11, Mike Crowe wrote:
> Well, it's a bit of an anomaly. I always understood that ccache was
> capable of being symlinked to from any name and it would just cope by
> executing the correct program further down the path. It seems rather
> odd if there is one program for which it doe
When making relative pathnames try and do so both before and after
calling realpath and pick the version that is the shortest. This helps
if the build starts from a path that contains a symlink and a Makefile
somewhere decides to use realpath to generate absolute paths.
It might be cheaper to do t
>For usage of ccache at our company, here is one of our biggest hassles today:
>even with the CCACHE_BASEDIR feature, users complain when gdb points to files
>that no longer exist.
>
>Independently, a couple of our engineers have proposed the following fix :
>
>1. On a cache miss, generate prepr
On 2011-02-15 13:51, Mike Crowe wrote:
>> It might not be expected for cpp to be a symlink to ccache but with
>> ccache-v2.4 it did used to work so I found it easier for our build
>> system just to symlink everything in the toolchain directory to ccache.
>>
>> Unfortunately between v2.4 (Debian Le
I like this idea.
I imagine the overhead of even a naive search-and-replace will be
pretty small compared to the hashing ccache does in direct mode, since
ccache currently hashes all of a file's #includes.
But if you want to make the search-and-replace really fast, you could
choose your nonce in
For usage of ccache at our company, here is one of our biggest hassles today:
even with the CCACHE_BASEDIR feature, users complain when gdb points to files
that no longer exist.
Independently, a couple of our engineers have proposed the following fix :
1. On a cache miss, generate preprocessor
