<div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 29, 2012 at 1:16 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank" class="cremed">jordan_rose@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 style="word-wrap:break-word"><div><div class="h5"><br><div><div>On Jun 29, 2012, at 12:52 , Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.com</a>> wrote:</div>
<br><blockquote type="cite"><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><div>       - 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></div></blockquote><br></div></div></div><div>I would personally like the tools to be <i>plugins</i> for the server. Even if they end up being statically linked, it'd still be nice to be able to build with only some enabled, say. And once you have that it's more acceptable (in my mind anyway) to have some of them live out of tree.</div>
</div></blockquote><div><br></div><div>I completely agree, and that was the design I planned to follow. (Specifically, both static linking and "pluggable" by checking out more code into the same tree before building the server. I *do not* want dynamic loading in a multithreaded system.) </div>
<div><br></div><div>But it does complicate things because it means:</div><div>- The architecture of the separate repo is a bit tricky and has to work to support code sharing at the library level. This is good, but an added complexity.</div>
<div>- We'll want to have some core functionality in the server that Always Works. But what is that functionality? It's hard for me to (currently) draw a clear line.</div><div><br></div><div>Regardless of where the line goes, even if for some reason we decide that *all* of the tooling logic to ever get contributed to this open source project, we still have to have the statically pluggable layout IMO, because lots of users will want to drop their custom and special tooling logic in that is highly specialized, inappropriate (or impossible) to open source, etc.</div>
</div></div>