On Mar 26, 2012, at 4:08 AM, Manuel Klimek <[email protected]> wrote:

> On Wed, Mar 21, 2012 at 10:44 PM, Marshall Clow <[email protected]> wrote:
>> On Mar 21, 2012, at 8:07 AM, Manuel Klimek wrote:
>>> On Wed, Mar 21, 2012 at 3:09 PM, Marshall Clow <[email protected]> 
>>> 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.

>> 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.

        - Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to