[cfe-dev] Where should tooling logic live? I have no idea...

Chandler Carruth chandlerc at google.com
Fri Jun 29 12:52:21 PDT 2012

I have a specific question about one of your points that is much more meta
than the original thread:

On Fri, Jun 29, 2012 at 9:09 AM, Douglas Gregor <dgregor at apple.com> wrote:

>        - It should live in a separate repository of Clang tools alongside
> (but not a part of) the main Clang repository.

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.

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?

Some observations that have motivated my initial guesses:

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
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.
3) I suspect that truly generic refactoring tools (let's say for example, a
'rename' tool) could very reasonably go either direction.
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
4) The idea of a Clang service layer complicates this -- in that model
*all* of the tools should be libraries bundled into the server.

Combining those observations leaves me with no clear feeling for where
things should live.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120629/e6b09ab8/attachment.html>

More information about the cfe-dev mailing list