Re: [ccache] Making ccache and clang compatible

2012-07-11 Thread Lubos Lunak
On Wednesday 11 of July 2012, Max Horn wrote:
 On 11.07.2012, at 02:34, Martin Pool wrote:
  On 5 July 2012 21:35, Mike Frysinger wrote:
  On Wednesday 04 July 2012 09:53:46 Max Horn wrote:
  err, -I/-isystem/-D/-U/etc... are preprocessor flags and are valid when
  in preprocessor mode (-E).  i don't know if clang is broken, or your
  is incorrect, but certainly that behavior you describe is wrong.
  I agree with you there, Mike,

 As do I, actually -- sorry, my email was indeed nonsense and confused. What
 I *meant* was that on the second run (the one without -E, with preprocessed
 data as input), clang prints out warnings.

 Now, I am not saying that ccache is doing anything wrong here,

 But you probably could. -I, -D, -U etc. are preprocessor options and not 
compiler options, and the preprocessor is (at least in the separate 
compilation steps theory) not run when the driver is fed preprocessed source.

  but I think the bug originally described in could possibly be valid.
  If you are compiling from a .i or .ii file, the -D and -I options can't
  have any effect.  It's reasonable for clang to emit a warning about it,
  and it would be reasonable for ccache to strip those options when
  compiling a preprocessed file.

 Aye, if that would be acceptable for the ccache authors, that would be the
 best solution I think.

 The best option is to use CCACHE_CPP2 with Clang. Giving Clang preprocessed 
source causes a number of small problems, such as some warnings not being 
suppressed or error/warning messages quoting modified source code. As a 
side-effect, this problem with preprocessor options will not exist with 
CCACHE_CPP2 either. It is a question how much not using CCACHE_CPP2 with 
Clang would improve performance anyway.

 Lubos Lunak
ccache mailing list

[ccache] GCC '@' parameters

2012-07-11 Thread Boie, Andrew P
I've been playing around with using the 3.x series of ccache to speed up 
Android builds (they by default use an old 2.x prebuilt copy) and have run into 
an incompatibility where I get 'unsupported compiler option' when the @file 
parameter is used. Android started using this extensively in Jelly Bean.

From the documentation in

Read command-line options from file. The options read are inserted in place of 
the original @file option. If file does not exist, or cannot be read, then the 
option will be treated literally, and not removed.
Options in file are separated by whitespace. A whitespace character may be 
included in an option by surrounding the entire option in either single or 
double quotes. Any character (including a backslash) may be included by 
prefixing the character to be included with a backslash. The file may itself 
contain additional @file options; any such options will be processed 

However any invocation of ccache where this is used in the GCC command line 
results in Unsupported Compiler Option with ccache 3.x:

[2012-07-11T12:02:49.208752 11127] Compiler option 
 is unsupported

ccache 2.x seems OK with this, but is probably computing incorrect command line 
hashes since it's not diving into the file to see the command line options 
within. Any advice for getting around this?

Andrew Boie
ccache mailing list