PATCH: Expose the 'file' that is associated with a compile database command

[Manuel Klimek via cfe-commits]

On Thu, Sep 10, 2015 at 8:36 PM Argyrios Kyrtzidis <kyrtzidis at apple.com>
wrote:

> On Sep 10, 2015, at 1:48 AM, Manuel Klimek <klimek at google.com> wrote:
>
> @@ -179,11 +185,13 @@ public:
>    /// \param Directory The base directory used in the
> FixedCompilationDatabase.
>    static FixedCompilationDatabase *loadFromCommandLine(int &Argc,
>                                                         const char *const
> *Argv,
> -                                                       Twine Directory =
> ".");
> +                                                       Twine Directory =
> ".",
> +                                                       Twine File =
> Twine());
>
> A fixed compilation database returns the same command lines for all files,
> thus having a file in the function seems strange.
>
>
> Ah ok, thanks for clarifying.
>
>
> What exactly is the use case? So far, the compilation database has been
> designed for 2 use cases:
> 1. for a file, get the compile commands; the user already knows the file,
> no need to get the file
> 2. get all compile commands; for that, we have the getAllFiles() method,
> so a user can get all known files (for compilation databases that support
> that), and then get the compile command line.
>
>
> It’s #2, I want to get all compile commands. But it seems really strange
> to me that the ‘file’ starts as a property of the compile command in the
> json file but then it gets dropped and I need to do work to re-associate
> the files with the compile commands again.
>

The JSON file format is one possible implementation for the
compilation-database interface. The FixedCompilationDatabase is another
one, that doesn't have any information on files.


> I need to get a list of all the files and then for each one do a lookup to
> get the associated commands. I then have to maintain this association
> myself, passing a command along with its file separately or the structure
> that keeps track of the association.
>
> It seems simpler to me to include the file that was associated with the
> command (if the compilation database supports that) along with the command,
> is there a downside I’m missing ?
>

Well, to me, it's a design question - if it also makes sense to have a
CompileCommand without a file associated with it, putting the file in
there, while convenient, is a design smell.
That said, I'm happy to be convinced that I'm wrong :) I guess I don't see
yet that keeping track of the files outside is more than one line of extra
code.

Cheers,
/Manuel


>
>
> Thoughts?
> /Manuel
>
> On Wed, Sep 9, 2015 at 9:36 PM Argyrios Kyrtzidis <kyrtzidis at apple.com>
> wrote:
>
>> Hi,
>>
>> The attached patch exposes the ‘file’ entry in a compilation database
>> command, via the CompileCommand structure.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150911/b6b979e6/attachment.html>