<div class="gmail_extra"><div class="gmail_quote">I have a specific question about one of your points that is much more meta than the original thread:</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Fri, Jun 29, 2012 at 9:09 AM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank" class="cremed">dgregor@apple.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="HOEnZb"><div class="h5">       - It should live in a separate repository of Clang tools alongside (but not a part of) the main Clang repository.<br>
</div></div></blockquote><div><br></div><div>I think it's clear we will need some side repository that is home of contributed tools that are maintained and released along with Clang, but not necessarily of interest to everyone.</div>
<div><br></div><div>What isn't clear to me is how we should decide when a tool belongs there or should actually come along with the core Clang checkout. My initial guess at where this tool should live was actually in the core Clang repository, so I suspect you have a different set of heuristics you're using. Could you elaborate on them?</div>
<div><br></div><div>Some observations that have motivated my initial guesses:</div><div><br></div><div>1) It seems like 'clang-check' and maybe 'clang-fixit' (which should be the Tooling analog to clang -fixit-always) are really good tools to put directly in the Clang tree</div>
<div>2) It seems like ad-hoc tools like the one which removes redundant calls to std::string::c_str() should not be in the main Clang tree.</div><div>3) I suspect that truly generic refactoring tools (let's say for example, a 'rename' tool) could very reasonably go either direction.</div>
<div>3.1) I suspect that this will be motivated by the fact that the generic refactoring logic will be structured as a library, shared by lots of tools</div><div>4) The idea of a Clang service layer complicates this -- in that model *all* of the tools should be libraries bundled into the server.</div>
<div><br></div><div>Combining those observations leaves me with no clear feeling for where things should live.</div></div></div>