PATCH: Expose the 'file' that is associated with a compile database command
Argyrios Kyrtzidis via cfe-commits
cfe-commits at lists.llvm.org
Thu Sep 10 11:36:01 PDT 2015
> 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.
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 ?
>
> Thoughts?
> /Manuel
>
> On Wed, Sep 9, 2015 at 9:36 PM Argyrios Kyrtzidis <kyrtzidis at apple.com <mailto: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/20150910/9d17d83e/attachment.html>
More information about the cfe-commits
mailing list