[cfe-commits] [PATCH] Implements support to run standalone tools

Marshall Clow mclow.lists at gmail.com
Wed Mar 21 07:09:14 PDT 2012

On Mar 21, 2012, at 6:25 AM, Manuel Klimek wrote:

> So, I've looked through the design ideas and I have a few follow up
> questions / remarks.
> On Wed, Mar 14, 2012 at 1:35 PM, Douglas Gregor <dgregor at apple.com> wrote:
>> I suggest a more general architecture that separates out the "program build" database from the code that parses code and runs the action on that code. To be a bit more concrete, I'm suggesting splitting ClangTool into two subsystems:
> Just to reiterate: I think this is a great idea.
>>        - An abstract class CompilationDatabase that allows one to iterate over the CompileCommands that went into a particular build (or apply some function object to each CompileCommand), along with:
>>                - A subclass JSONCompilationDatabase that retrieves CompileCommands from the JSON output produced by CMake
>>                - A subclass SimpleCompilationDatabase where one programmatically adds CompileCommands
>>                - Note: it should be possible for us to create additional compilation database kinds, e.g., by parsing makefiles directly
>>                - A function that makes it easy to take argc/argv an interpret it either as a use of JSONCompilationDatabase or SimpleCompilationDatabase. This should make it easy to create a unified command-line interface to Tooling-based Clang tools, so it's easy for end users to run different tools on their projects
> I'm not sure why we'd need argc/argv here. I'd propose a function like
> (stealing from what you wrote further down, slightly changing it):
> /// \brief Loads a compilation database from a build directory.
> ///
> /// Looks at the specified 'BuildDirectory' and creates a compilation
> database that allows to query compile commands for source files in the
> corresponding source tree.
> /// Returns NULL if we were not able to build up a compilation
> database for the build directory.
> /// FIXME: Currently only supports JSON compilation databases, which
> are named 'compile_commands.json' in the given directory.
> CompilationDatabase *loadCompilationDatabase(StringRef BuildDirectory);

I think that Doug's point here is that sometimes you want to get your options/list of files from either a Makefile or argc/argv, rather than a JSON file, and putting a layer of abstraction here ("compilation database"), lets you do that.

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists at gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

More information about the cfe-commits mailing list