On Mar 26, 2012, at 7:21 AM, Manuel Klimek <[email protected]> wrote:
> On Mon, Mar 26, 2012 at 3:56 PM, Douglas Gregor <[email protected]> wrote: > > 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. > > 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
