(No comment was entered for this change.)

Sounds like a good goal. However, the clang analyser is LGPL and LLVM so we'd need to be careful about 
redistribution. It would probably be enough to have the ObjectivEClipse code be able to parse the output 
from clang, and translate those (but without shipping the clang itself). It might be the case that we could 
package up a version of clang for invocation programmatically in a bundle but would have to be done 
outside of the core objectiveclipse bundles (though I don't see any reason why we couldn't host it on this 
project in a separate bundle). If there's any question of licensing issues for later inclusion at Eclipse.org, 
we'd simply leave the binary bundle behind.

I note that the build instructions say 'this can take some time'. It also seems to need to ahve a full build 
done; if you run it, then run it a second time, it will say 'nothing to do' (at least, via xcodebuild).

If you run it without -v, the output doesn't get generated but simply dumped into HTML files (which won't 
be easy to parse). On the other hand, if you run it with -v, it gives you the message and file/location name, 
which should be easy enough to hook in.

alex$ scan-build -v -o foo xcodebuild -sdk iphonesimulator3.0 | grep "Value stored"
2009-08-02 08:40:25.562 xcodebuild[33448:613] warning: compiler 
'com.apple.compilers.llvm.clang.1_0.analyzer' is based on missing compiler 
'com.apple.compilers.llvm.clang.1_0.analyzer'
/Users/alex/Projects/MyProject/Foo.m:660:25: warning: Value stored to 'foobar' is never read

I suspect that if you just replaced the 'gcc' phase with 'scan-build' in the project's makefile, and did a clean 
all, then it would just display the values as expected.

NB I think an additional tool is probably a good idea rather than a builder - as the documentation notes, it's 
quite time consuming (and requires a full build). So having this build every time might be overly expensive. On 
the other hand, having it as a tool which can be run in the background might be useful.

FWIW I tried to run scan-build on a CDT project from the terminal, and it didn't seem to generate any reports. 
I'm not sure if I have some odd directory set up, but it would be worth confirming that we can run scan-build 
externally to the CDT project before trying to hook it in.

The clang analyzer isn't LGPL, its distributed under the LLVM license, which appears
to be a '3 clause BSD' style license. Regardless I hadn't intended that we'd include
the analyzer, just provide an interface to one that the user already has installed.

This would be a great feature, but you should consider using the new CDT framework
for static analysis (http://wiki.eclipse.org/CDT/designs/StaticAnalysis) for this
job. I don't know how much is really implemented but it should be worth trying out. 

The static analysis framework isn't part of the Galileo release, which is what ObjectivEClipse is currently 
targetting, whereas the clang static tool is something that can be applied to an existing system.

I just successfully tried to embed cppcheck with the Codan framework (only using its
error logging capabilities and option to run the check with the build). The part,
which is already in CVS is at least a good starting point and makes it very easy to
embed external code checkers. You could make use of that code already in svn to
release the ObjectiveEClipse static analysis. Then it would be easier to port it to
that framework if it becomes part of a future Eclipse CDT release. But this is of
course only a suggestion. If you are interested I can give you the source (very rough
draft) I wrote to embed cppcheck.

Sounds good. Can you file a separate issue so we can distinguish this one (clang) from cppcheck?