Using scan-build with iPhone XCode project


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.


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).