<div class="gmail_quote">On Tue, May 29, 2012 at 7:43 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, May 29, 2012 at 06:50:11PM +0200, Manuel Klimek wrote:<br>
> Yes. But if you want to statically analyze a whole code base for global<br>
> information, you need to analyze every TU (as you would need to compile<br>
> every TU). Having a dependency graph restriction in here would lead to<br>
> sequential bottlenecks (which make -j shows).<br>
<br>
</div>This part I don't understand. What kind of dependency graph restrictions<br>
are you thinking about? If you have functional dependencies of one TU on<br>
another TU, you can't just drop those. Consider build tools like yacc for<br>
an integrated OS build as example.<br></blockquote><div><br></div><div>This is exactly what I meant when I wrote: "<span style>On the other hand, having global analysis of course still relies on the build, as generated sources need to be available. But given that we often want to run multiple iterations of static analysis at a single point of the code, this pays of big time."</span></div>
<div><span style><br></span></div><div><span style>Note that this is *not* about running something when you change code (that's what build tools are for), but to run a tool when you want to change something, or to run multiple static analysis runs on the same code point.</span></div>
<div><span style><br></span></div><div><span style>Cheers,</span></div><div><span style>/Manuel</span></div><div><span style><br></span></div></div>