<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 29, 2012, at 12:52 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><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 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>
</blockquote></div><div><br></div><div>I see the main Clang repository as being responsible for:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>1) The compiler proper</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>2) IDE integration</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>3) Clang service layer (when it happens)</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>4) Infrastructure to build Clang-based tools and plugins</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>5) Testing infrastructure for all of the above</div><div><br></div><div>To me, that's the core of what Clang *is*. Things like the static analyzer, ObjC rewriter, ARC migrator, c_str() pruner, C++11 migrator, etc. are outside of that core and should eventually live in the side repository.</div><div><br></div><div>I worry a little bit about the side repository becoming broken. Obviously, there's an additional testing burden to consider here, and I do worry (in the abstract) that we'll be making trouble for ourselves by having to maintain a pile of standalone tools outside of the main repository. But, I think we can handle this.</div><div><br></div><div>The Clang service layer does complicate this. Allowing the server to load plugins would solve the issue for plugins that ride on the normal compile jobs. Perhaps we can make it not completely painful to turn a standalone tool into a plugin that can be loaded by the server.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></body></html>