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

> On Mon, Mar 26, 2012 at 4:26 PM, Douglas Gregor <[email protected]> wrote:
> 
> 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:
> 
>> 
>> >> 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.
> 
> Agreed. So something like:
> 
> /// \brief Specifies the working directory and command of a compilation.
> struct CompileCommand {
>   /// \brief The working directory the command was executed from.
>   std::string Directory;
> 
>   /// \brief The command line that was executed.
>   std::vector<std::string> CommandLine;
> };
> 
> class CompilationDatabase {
> public:
>   /// \brief Returns all compile commands in which the specified file was 
> compiled.
>   ///
>   /// This includes compile commands that span multiple source files.
>   /// For example, for a compile command line
>   /// $ clang++ -o test a.cc b.cc t.cc
>   /// $ clang++ -o production a.cc b.cc -DPRODUCTION
>   /// A compilation database representing the project would return both 
> command lines 
>   /// for a.cc and b.cc and only the first command line for t.cc.
>   virtual vector<CompileCommand> getCompileCommands(StringRef FilePath) = 0;
> };

Sure. Returning vectors is cheap now! ;)

> Also, I'd like to pull CompilationDatabase into its own header file if that 
> is fine with you.

Yes, please.

        - Doug

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

Reply via email to