[ccache] Stumbling blocks with ccache and embedded/encapsulated environments

Paul Smith paul at mad-scientist.net
Wed Dec 1 19:47:28 MST 2010

Hi all; I got sidetracked on this for a while but I'm back at it.

So, I think I have the encapsulated compiler working OK now; I am able
to get almost complete sharing of objects between two workspaces; after
a clean build of (just a small part of) the first workspace my cache

        cache hit (direct)                     0
        cache hit (preprocessed)              11
        cache miss                           214
        files in cache                       439

Then after an identical build command in my second workspace my cache

        cache hit (direct)                   225
        cache hit (preprocessed)              11
        cache miss                           214
        files in cache                       439


Now I'm on to my next problem.  In order to get this to happen I have to
set CCACHE_BASEDIR to strip off the workspace directory prefix, so that
the per-workspace filenames are not embedded in the cache.  This works
(see above), however the result is not so nice.

When my compiler is invoked it is run from an object output directory
then uses the fully-qualified name of the source file/include dirs etc.;
for example:

        cd /path/to/ONE/obj/subdir/foo
        my-special-gcc -c -o /path/to/ONE/obj/subdir/foo/foo.o \

Then I run ccache with CCACHE_BASEDIR=/path/to/ONE for example.

When ccache invokes my compiler, it runs like this:

        cd /path/to/ONE/obj/subdir/foo
        my-special-gcc -c -E ../../../src/subdir/foo/foo.c

This works, as you can see above.  But, it's a serious drag from a
debugging standpoint, because now the pathname for that file in my debug
information is _based on the obj/subdir/foo directory_.

That means that basically in gdb I have to add EVERY DIRECTORY (or at
least, one directory at every level) to my source file search path, so
that when the "../../../" is added the right thing is found.

In other words I can't just add "/path/to/ONE" to the GDB search path,
because "/path/to/ONE/../../../src/subdir/foo/foo.c" obviously doesn't
exist.  I have to add a directory at each level so that when GDB adds
the relative path to it, the right value is found.


What I'd really like is for ccache to do this:

        cd /path/to/ONE
        my-special-gcc -c -E src/subdir/foo/foo.c

then write the .o out into /path/to/ONE/obj/subdir/foo as it would have

I do realize it is very dangerous in general for ccache to use a
different working directory than the one it started in, because there
could be -I options etc. on the command line which are relative to the
working directory and not fully-qualified.  In my particular case,
though, that's not an issue since all my paths ARE fully-qualified.

But, I'm not sure I know how else to get this working; it seems like a
pretty serious problem.  Has anyone else on the list gotten sharing
between workspaces to work properly, and if so how did you deal with
these issues?


More information about the ccache mailing list