<div class="gmail_quote">On Thu, Apr 28, 2011 at 2:23 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com">klimek@google.com</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 Thu, Apr 28, 2011 at 2:03 PM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>
><br>
> On Apr 28, 2011, at 1:57 PM, <a href="mailto:klimek@google.com">klimek@google.com</a> wrote:<br>
><br>
>> Reviewers: chandlerc,<br>
>><br>
>> Description:<br>
>> Looks like it should have been there all along - clang-check is a useful<br>
>> tool for quick feedback editor-integration.<br>
>><br>
>> Please review this at <a href="http://codereview.appspot.com/4449067/" target="_blank">http://codereview.appspot.com/4449067/</a><br>
><br>
> One of the reasons that it isn't in tools is that we don't want to build it all the time.  The incremental cost of linking all the libraries into yet-another-tool is quite high.  Why is this useful?<br>
<br>
</div>>From our experience at Google this is one of the favorite tools of our<br>
developers, as it allows fast feedback while coding from vi or emacs<br>
without the need to invoke the build.</blockquote><div><br></div><div>Yea, in particular, this was seen as a really killer tool when folks rigged up a ":clang_check" vim or emacs command that would invoke it on the file in the current buffer after a quick save. It's basically a way to get the "clang compile" button of xcode into other environments.</div>
<div><br></div><div>That said, if its slowing down builds, is there a way we can mark specific tools as optional? It seems more important to have the code and the tool be discoverable in the tree than be built every time if people aren't using it... </div>
</div>