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

[Douglas Gregor]

On Mar 26, 2012, at 7:21 AM, Manuel Klimek <klimek at google.com> wrote:

> On Mon, Mar 26, 2012 at 3:56 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> On Mar 26, 2012, at 4:08 AM, Manuel Klimek <klimek at google.com> wrote:
> 
> > On Wed, Mar 21, 2012 at 10:44 PM, Marshall Clow <mclow.lists at gmail.com> wrote:
> >> On Mar 21, 2012, at 8:07 AM, Manuel Klimek wrote:
> >>> On Wed, Mar 21, 2012 at 3:09 PM, Marshall Clow <mclow.lists at gmail.com> wrote:
> >>>> On Mar 21, 2012, at 6:25 AM, Manuel Klimek wrote:
> >> I think I understand now.  The point that I was trying to make is that I think that for simple tools we (or at least I) would like to be able to forego building some kind of database (JSON, Makefile, Ninja), and just specify the options and source files on the command line.
> >>
> >> $ ./oneOffTool -I blah -Dblix=4 -I other_dir -o output_dir -someCustomFlag *.cpp
> >>
> >> As long as we're abstracting the idea of a "compilation database", I think that generating such a db from an argc/argv pair seems like a good idea (and not very hard).
> >>
> >> Hopefully what I'm trying to convey is clearer now.
> >
> > Well, the interesting thing is how to design this. From a design point
> > of view, the command line becomes very different depending on whether
> > you basically want to "forward all args to clang in the tool" or "find
> > the args for the specified files and run the clang tool over them".
> > The first one inherently means I can only specify the command line for
> > a single invocation, so it is also pretty limited. I agree it is an
> > important use case though.
> >
> > A possible solution would be to allow for a command line flag that
> > switches to use the command line arguments directly as arguments for
> > the clang tools. My problem is that I don't really see a good way to
> > handle that with llvm-provided command line abstractions (perhaps I'm
> > missing something there?)
> >
> > What I basically want would be:
> > <tool> -d <build directory> <file1 ... fileN>
> > <tool> --use-args <clang command line>
> >
> > But I don't want to roll my own command line parsing if possible.
> 
> I could be something as trivial as
> 
>        <tool> <tool arguments> -- <clang command line>
> 
> where the lack of "--" means that the tool should expect a build directory in <tool arguments>. You'd need to look through argv to find the "--" and split at that point, but the rest of the command-line parsing would be unchanged.
> 
> I like the idea. I'll play around to see whether I can get the llvm command line parsing to behave like I want to.
> I can probably just feed the part of the command line before the "--" to the llvm command line parsing.

Yeah, I think it's fine to just feed everything before "--" to the llvm command-line parsing.

> I'd probably like to write something like (leaving figuring out how to pack that up to make writing simple tools simpler for later):
> <define tool command lines>
> int main(...) {
>   // Make argc and argv references so we can change them? Kind of yuck, alternative ideas welcome.
>   llvm::OwningPtr<CompilationDatabase> Database(createSimpleCompilationDatabase(argc, argv));
>   <do llvm command line parsing on rest of argc, argv>
>   if (!Database) {
>     Database.reset(loadCompilationDatabase(BuildDirectory));
>   }
>   ClangTool Tool(Database.get(), Filenames);
> }
> 
> where SimpleCompilationDatabase then returns the same arguments independent of the file name...
> 

Agreed.

> 
> >> Then again, when you say "CompilationDatabase", I think of something that I can extract a set { commands, arguments, source file } tuples to be executed.
> >> Maybe that's where we are are talking past each other.
> >
> > When I say CompilationDatabase I think of a map<filename, { command,
> > arguments, path}>. Does that make sense?
> 
> 
> Makes sense to me, although of course this could end up being a multimap.
> 
> Which is also an interesting design question - at least for refactorings we'll probably want to run over all different command lines the file was compiled with (think: different configurations with different macros enabled). This would lead to a slightly different interface for CompilationDatabase though (returning a list of compile command lines for each target).

I think it's important for us to support this case in the interface.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120326/6c3c5b60/attachment.html>