On Sun, Jun 13, 2010 at 18:38, Joel Rosdahl <[email protected]> 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. Bernhard. _______________________________________________ ccache mailing list [email protected] https://lists.samba.org/mailman/listinfo/ccache
