<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 30, 2014, at 10:12 PM, James Burgess <<a href="mailto:jamesrburgess@mac.com" class="">jamesrburgess@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Now I壇 like to integrate this into my own build system. I read that if I was using make/autoconf (which I am not) I could just set CC and CXX and the right thing would happen?</span><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I can see scan-build doing the same but most of the script seems to be about building the report html, I知 guessing I知 going to need some of that script after my build is done. Does anyone know what would be the recipe if for doing that if I had a large pile of makefiles and I壇 set CC and CXX before building?</span><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div class=""><br class=""></div><div class="">The "-isysroot" option points the compiler to an SDK. Normally when you run gcc (which really is 'clang' on newer OS X installations) it is a shim to run "xcrun clang", which in turns invokes clang with the proper SDK path. scan-build is interposing on the Makefile's compiler, and invoking clang to run static analysis. The clang it is using, however, is the clang that came with the checker tar file, and you're not getting the automatic SDK inference that happens when you run the system clang with no SDK option.</div><div class=""><br class=""></div><div class="">When Xcode (and xcodebuild) invokes clang it always passes an explicit "-isysroot" option, which is probably why nobody using the checker builds with Xcode projects has reported a problem.</div><div class=""><br class=""></div><div class="">I think you could hack your Makefile to include an explicit "-isysroot" for OTHER_CFLAGS, but I think this is unnecessary. You are really working around a limitation in scan-build.</div><div class=""><br class=""></div><div class="">I think one of the following two things should happen:</div><div class=""><br class=""></div><div class="">(1) ccc-analyzer (which is the fake compiler driver invoked by scan-build) should add an implicit -isysroot when running clang when no -isysroot is provided.</div><div class=""><br class=""></div><div class="">(2) We change how scan-build does interposition of the compiler during build time to use a different method that doesn't guess what the host compiler would do, but observes it directly and replicates that logic. Right now we interpose essentially at the build system level, which doesn't get all the implicit logic that the host compiler has.</div><div class=""><br class=""></div><div class="">I've hacked up a solution for #2. Could you try copying the attached ccc-analyzer file into the 'libexec' directory of your untarred checker directory and see if that solves the problem.</div><div class=""><br class=""></div><div class=""></div></div></div></div></blockquote><br class=""></div><div class="">Yes that seems to work for me too. I no longer need the isysroot option. </div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Great. I committed that change in r225038.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">FWIW I would be quite happy to add the -isysroot option to my build system for a static analysis build but having scan-build discern it in its absence seems ok too.</div><div class=""><br class=""></div><div class="">So back to my second question, like I said, I知 not using Makefiles but if I had the recipe for getting that to work I could more easily integrate this into my own build system since I知 very familiar with make. If in make all I need to do is set CC and CXX to point to the checker version of clang then I believe there値l need to be some post process to build the html that the scan-build script does. Is that correct?</div><div class=""><br class=""></div></div></blockquote><div><br class=""></div><div>You are really raising a larger question of how best to integrate the static analyzer into a build system.</div><div><br class=""></div><div>It's a nuanced answer. The idea is that we want the analyzer to see the code in the same way that the compiler does when performing a build. Right now we're doing a poor man's interposition by overriding CC and CXX; that's essentially all scan-build does to interpose the analyzer into a (say) Makefile build. By changing the compiler used by make, the build system invokes a fake compiler driver that invokes the real compiler and then invokes clang for doing static analysis. Each file is separately analyzed and report files are generated. Once the build completes, scan-build collates the HTML report files and builds an index.</div><div><br class=""></div><div>There's two design points at play here that I think are worth noting:</div><div><br class=""></div><div>(1) This interposition is not a great hack. Sometimes the build system doesn't control every compiler innovation. For example, a Makefile build could spin off a shell script that invokes the compiler, and that script may not consult CC or CXX. Also, some Makefiles (or whatever) hardwire the compiler they use, thus setting CC or CXX has no effect. Unless the build system has total control of the compilation jobs, the only sure way to interpose on all compiler instances is to do true OS interposition. This can be accomplished in various platform-specific ways on different platforms, and is the approach taken by several commercial static analysis tools.</div><div><br class=""></div><div>(2) The way we do analysis and gather reports could hypothetically change in the future. Right now we analyze each file at a time, generate reports, and then stitch the reports together. In the future, a reasonable direction for the analyzer would be do two phases of analysis: first do a pass over the files like we do now, and then do a more global analysis to find bugs that cross file boundaries. This approach would inherently defer the generation of reports to the very end. Also, the mechanism by which reports are generated could change. Right now HTML files are generated eagerly, but those really are a static rendering. A more versatile approach would be to generate output that summarizes the bug reports, and have the HTML reports (or whatever) generated from those.</div><div><br class=""></div><div>Digesting it down:</div><div><br class=""></div><div>(a) There's a danger of embedding too much knowledge of how the static analyzer works into the build system because the static analyzer could change in how it works or the build system may not have complete knowledge of the build process.</div><div><br class=""></div><div>(b) If you want to integrate the analyzer into the build system, I'd keep the interfaces at a high level such as doing a pass over the files and doing a post-process after build. The post-processing should possibly be done by something controlled by the static analyzer tool, not integrated into the build system. This gives you the ability to integrate the analyzer into your build system but allow you to worry less about disruptive changes down the road.</div><div><br class=""></div><div>Note that in Xcode we integrated knowledge of the analyzer into Xcode's build system. There are distinct advantages of doing that as well: tight control of the analyzer from the build system, ease of management of resources like PCH (currently scan-build doesn't handle PCH files at all, so they are disabled), etc. But with Xcode we are fully cognizant that the integration of the analyzer may need to change over time as the analyzer changes as well.</div><div><br class=""></div><div>But back to this reasonable question:</div><div><br class=""></div><div><blockquote type="cite" class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""> If in make all I need to do is set CC and CXX to point to the checker version of clang then I believe there値l need to be some post process to build the html that the scan-build script does. Is that correct?</div></div></blockquote></blockquote><br class=""></div><div>The answer is "yes" with caveats. As I pointed out above not everything honors CC and CXX (e.g., uses an explicit compiler path), but in such cases the behavior will likely be the same as what you get with scan-build (i.e., files that aren't analyzed).</div></div></body></html>