[ccache] [PATCH] Some patches for Xcode support

Bernhard Bauer bauerb at google.com
Sun Jun 13 12:22:24 MDT 2010

On Sun, Jun 13, 2010 at 18:38, Joel Rosdahl <joel at rosdahl.net> wrote:
> On 2010-06-11 15:18, Bernhard Bauer wrote:
>> I finally got around to rewriting the third patch. I added a special
>> case to process_args that matches distcc's behavior (if the first
>> argument to distcc is neither a source/object file nor an option, it's
>> treated as the compiler).
> Thanks. One problem with the patch is that if ccache is invoked as
> distcc, ccache will hash the mtime (or content) of distcc instead of the
> compiler when trying to detect compiler changes. (See
> CCACHE_COMPILERCHECK in calculate_common_hash().)
> Also, it feels a bit strange to add a special case for distcc, so I
> would like to understand more about the problem to solve. You said
> earlier that distcc is called directly by xcodebuild and that you're
> masquerading ccache as distcc via a symlink. Is the following a correct
> guess of the setup?
> 1. /X/distcc is a symlink to ccache.
> 2. xcodebuild runs "/X/distcc compiler arguments".
> 3. ccache determines (with your patch) that it's invoked as distcc.
> 4. ccache uses "distcc compiler arguments" as the compiler command and
> the real distcc is found in PATH.

Yes, that's the setup. A small additional detail is that the compiler
is also called with an absolute path, so without the patch ccache
determines that it's a valid file and assumes it's an input file.

> If so, wouldn't an alternative solution be to replace /X/distcc with a
> script like this:
> #!/bin/sh
> CCACHE_PREFIX=distcc exec ccache "$@"

That should work, provided PATH is modified to exclude /X, otherwise
ccache would call this script again when calling distcc (because it's
not a symlink to ccache).

> As a bonus, this will make ccache call the preprocessor as "compiler -E"
> instead of "distcc compiler -E", which avoids some extra processing.

I think the overhead from distcc alone is negligible, however running
the compiler directly frees up distcc slots on localhost, of which
there is a limited number (which could increase throughput because
more jobs are being preprocessed, or decrease it because of
thrashing). I'll try to find out if it helps performance, and  come
back complaining to you if it doesn't ;-)

>> Also, I added the -x option for compiling preprocessed code again if
>> there was an -x option on the original command line. Otherwise, when
>> compiling Objective-C code on a different machine, distcc wouldn't
>> recognize the code as preprocessed Objective-C.
> Is this because distcc doesn't know about .mi/.mii being precompiled
> code? Why is this a problem? And in that case, don't you need to add
> "-x" unconditionally (not only if explicit_language has been set)?

I had distcc failing complaining about a compiler option that's
specific to Objective-C, but only when running the job on another
host. My guess is that distcc (or at least the old version Apple is
shipping) doesn't recognize .mi/.mii as being Objective-C files, so on
the other host it writes them to a temp file ending in .i/.ii before
calling gcc, then gcc assumes they're plain c/c++ files. But yeah, in
that case I probably need -x always, I just didn't want to muck around
with the command line options any more than necessary.


More information about the ccache mailing list