<p dir="ltr"><br>
On Jul 7, 2013 6:37 AM, "Sylvestre Ledru" <<a href="mailto:sylvestre@debian.org">sylvestre@debian.org</a>> wrote:<br>
><br>
> On 06/07/2013 18:11, David Blaikie wrote:<br>
> ><br>
> > On Jul 6, 2013 7:34 AM, "Sylvestre Ledru" <<a href="mailto:sylvestre@debian.org">sylvestre@debian.org</a><br>
> > <mailto:<a href="mailto:sylvestre@debian.org">sylvestre@debian.org</a>>> wrote:<br>
> >><br>
> >> Hello,<br>
> >><br>
> >> After setting an automatic code coverage tool [1], I just plugged an<br>
> >> automatic scan-build on the LLVM toolchain:<br>
> >><br>
> >> <a href="http://buildd-clang.debian.net/scan-build/">http://buildd-clang.debian.net/scan-build/</a><br>
> >><br>
> >> Note that:<br>
> >> * polly is currently not analyzed. I had to disable the build until the<br>
> >> new version of cloog is available.<br>
> >> * compiler-rt is not analyzed because it does not respect the CC/CXX<br>
> >> argument to use the clang built locally [3]. Should I report a bug here?<br>
> ><br>
> > I'm not sure what bug to report here, if any, compiler-rt deliberately<br>
> > uses the just-built clang because it has to be in lock-step with it.<br>
> Or a wish to have compiler-rt checked with scan-build (while still using the<br>
> just-built clang)</p>
<p dir="ltr">I'm not entirely clear on how scan-build works, but I assumed it redefined cxx and cc to run the analyzer and then run the old value of cxx and cc, so I'm not sure how the build system for compiler rt would gracefully support that. The build wants yto set cxx and cc to point to the just built clang, which overrides the value set by scan-build, losing the interception.</p>
<p dir="ltr">><br>
><br>
> >><br>
> >> This work is done through the Debian/LLVM jenkins instance [2].<br>
> >> The report is updated twice a day.<br>
> >> The scan-build/clang used to produce the report is the one published on<br>
> >> <a href="http://llvm.org/apt/">http://llvm.org/apt/</a>. That means that a new feature/fix done on<br>
> >> scan-build will appear only about a day after on report. As a side<br>
> >> effect, it tests automatically the packages distributed on<br>
> > <a href="http://llvm.org/apt/">llvm.org/apt/</a> <<a href="http://llvm.org/apt/">http://llvm.org/apt/</a>>.<br>
> ><br>
> > Any reason this can't be a two stage and use the previous build to<br>
> > analyze the next?<br>
> For two main reasons:<br>
> * it is faster (I don't have to build clang during this process)<br>
> * it is easier in the current process of building the package.<br>
><br>
> However, I am planning to do it at some point.<br>
><br>
> Sylvestre<br>
><br>
><br>
</p>