[cfe-dev] Using scan-build with iPhone XCode project

[Ted Kremenek]

On Feb 10, 2009, at 2:42 PM, Francois Proulx wrote:

> Hi,
>
> I've got an iPhone XCode project which has a direct dependency over  
> a second XCode project producing a static library. This static  
> library is linked to my project. I've added an import to my  
> main .pch (precompiled header) file so I've got all the import for  
> my library (i.e : #import "BkCommon.h").
>
> All this builds perfectly well in XCode (I've had to add a relative  
> path in the "User header search path" to the directory where the  
> second project files are located). Here's the problem, when I run  
> "scan-build xcodebuild", it builds, but it gives me a bunch of  
> "analyzer issues" (I don't quite remember the term used). Looking at  
> the STDERR output shows that all the error are related to the  
> #import line in my .pch. It says that it can't find the file  
> "BkCommon.h". To me, it's as if scan-build is ignoring the "User  
> header search path"...
>
> Any help on the matter would be greatly appreciated.
>
> Thanks
> Francois

Hi Francois,

Two things:

(1) Right now, the analyzer only supports analyzing iPhone projects  
when they are in the "Simulator" configuration.  You may see misc.  
errors if you try analyzing a project when doing a "native" build.

(2) Clang doesn't read gcc pch files (and it never will).  This is why  
scan-build disables the generation of PCH files when the build command  
is 'xcodebuild'.  Clang will soon support its own PCH-like files, but  
these will be used in tandem with (or rather in place of) gcc's.

Two approaches that will probably work is to (1) simply not use PCH  
files at all when analyzing your project or (2) to copy the BKCommon.h  
file to the same directory where your PCH file is located.  In the  
latter case, Clang will then find your prefix file, even if it isn't  
precompiled.  This shouldn't effect gcc's performance, as it looks for  
the pch file first.

Ideally, we will want scan-build to do something that works a little  
more transparently.  The problem is xcodebuild (and potentially other  
build systems) often copies the PCH file to an alternate directory  
than the rest of the build and do not copy the original prefix file  
with it.  This means that Clang cannot find the prefix header (and as  
I mentioned before, it cannot read gcc's PCH files).

Ted