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. 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... > > >> 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). Thoughts? /Manuel
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
