[cfe-dev] Extending CMAKE_EXPORT_COMPILE_COMMANDS

[Manuel Klimek]

Looping in chandlerc for an opinion :)

On Mon, Jun 25, 2012 at 8:25 PM, Bertjan Broeksema <broeksema at kde.org>wrote:

> Manuel Klimek wrote:
>
> > On Thu, Jun 21, 2012 at 11:42 AM, David Röthlisberger
> > <david at rothlis.net>wrote:
> >
> >> On 21 Jun 2012, at 09:32, Manuel Klimek wrote:
> >> > I especially wouldn't want to change the key in the current
> >> > [compilation database] file format due to adding link commands. I'm
> >> > currently slightly leaning towards an extra file, because that leads
> to
> >> > tools that only
> >> care about
> >> > one part being simpler (and once you add one use case, you start
> adding
> >> other
> >> > use cases ;), but it's not a clear-cut decision.
> >>
> >> Correct me if I'm wrong, but the current file doesn't have an explicit
> >> key. It looks like:
> >>
> >>    [
> >>      { "directory": ...,
> >>        "command": ...,
> >>        "file": ... },
> >>      ...
> >>    ]
> >>
> >> Not like:
> >>
> >>    { "<file>": [{
> >>        "directory": ...,
> >>        "command": ... },
> >>        ...
> >>      ],
> >>      ...
> >>    }
> >>
> >> So users of this compilation database (currently) would have to build
> >> their own index anyway, if they decide they need it for performance
> >> reasons.
> >>
> >> Given the above, I don't think it would hurt to add an extra "output"
> >> element. And while we're at it --before there are too many users--
> >> rename "file" to "input" or something like that. Generate both "file"
> >> and "input" entries for a while, to ease the transition, but mark
> >> "file" as deprecated.
> >>
> >
> > Well, the idea is that "file" specified a main source file for a TU.
> >
> >
> >> Tools for working on C/C++ source files would, I imagine, independently
> >> obtain a list of source files (e.g. "find . -name '*.cpp'") and then
> >> look up each file in the compilation database. So it doesn't matter if
> >> the compilation database contains entries for non-source files (like a
> >> link command with input file "something.o"). Please correct me if your
> >> use case differs.
> >>
> >
> > Ah, yes, theoretically it doesn't matter, as long as the tools all
> > understand it and can throw away things they don't need.
>
> And for the linker part: I'd like to pass the command line as well to find
> the libraries against which an executable/librarie is linked as well other
> settings passed to the linker such as search directories and rpath.
>
> >> Similarly, my vote would be for something like
> >> CMAKE_EXPORT_BUILD_COMMANDS instead of separate
> >> *_COMPILE_COMMANDS and *_LINK_COMMANDS.
>
> I'm in favor of this as well, though for me its just a spare time project
> so
> if others have reasons related to scalability that are important to them, I
> can live with a separete file as well. I don't see how this would be
> formatted though, to be similar to the current file format. I suppose
> something like:
>
> // For compilation
> { "directory": ...,
>   "command": ...,
>   "input": <sourcefile>,
>   "ouput": <sourcefile>.o
> }
>
> // For linking
> { "directory": ...,
>   "command": ...,
>   "input": [<list of files here>] },
>   "ouput": <lib_or_exec_name>
> }
>
> Eventually one could add an extra level of properties to distinguish
> between
> the two types:
>
> {
>  compilations: [
>    { <compilation_objects }
>  ],
>  linkcommands: [
>    { <compilation_objects }
>  ]
> }
>
> To me that is a bit cleaner, but likely requires more work to existing
> tools
> that already use the format. In stead of that, an extra option can be set
> on
> each object:
>
> { "directory": ...,
>   "command": ...,
>   "input": [<list of files here>] },
>   "ouput": <lib_or_exec_name>
>   "type": <link|compilation>
> }
>
>
> > You raise good points - as I said, which way to chose is not clear cut,
> > and I'd be willing to say whoever implements it wins ;)
>
> Hehe, so I implement it however I want for my spare time project and burden
> people who use it in their daily work with some over engineered format =:).
>
> No, really, I just brought it up because this CMake extension looked really
> useful to me and if it exports the additional information, it makes life
> for
> me a bit easier. I'm willing to do the implementation, I just don't want to
> implement something that is rejected because others would have seen it
> differently after they see the implementation.
>
> So I prefer to settle for a solution first, then I'll sit down and add the
> feature.
>
> Cheers,
>
> Bertjan
>
> p.s. My reaction time is illustrating for what spare time means in my
> context =:)
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120628/b8309813/attachment.html>