[cfe-dev] compile_commands.json for Windows/MSVC

Manuel Klimek klimek at google.com
Wed Aug 14 02:22:49 PDT 2013


On Wed, Aug 14, 2013 at 2:10 AM, Kim Gräsman <kim.grasman at gmail.com> wrote:

> On Wed, Aug 14, 2013 at 11:00 AM, Chandler Carruth <chandlerc at google.com>
> wrote:
> >
> > On Wed, Aug 14, 2013 at 1:57 AM, Kim Gräsman <kim.grasman at gmail.com>
> wrote:
> >>
> >> I'd prefer to parse the VS project files and spit out a compilation
> >> database. They are plain XML and as of VS2010 (I think) supposed to be
> >> backward compatible, so it's a stable format.
> >
> > My problem with this is that it adds an extra step every time the project
> > file changes. If you forget it, your tool begins to misbehave in
> potentially
> > surprising ways.
> >
> > Maybe you could make the logic involve parsing and spitting out, but
> > embedding it into a plugin that gets notified when VS sees the project
> file
> > change? (I clearly have no idea how this stuff works...)
>
> I see your concern. Yeah, it could probably be driven from a plug-in
> of some kind, I don't know the details either. It thought it was messy
> when I looked at it last a few years ago :-)
>
> Isn't it just a dependency problem, though? If the modified time of
> any vcxproj > the modified time of compile_commands.json it needs to
> be regenerated? That way it would pick up changes that happen outside
> of Visual Studio, e.g. a version control update, manual edit,
> generated projects.
>
> Actually, I started digging into Tooling yesterday, and maybe
> compile_commands.json doesn't even need to be saved out. What if there
> was code in Tooling to transform a Visual Studio solution into a
> CompilationDatabase implementation? It would take longer to parse,
> probably, but it should be a pretty direct translation.
>

I think that'd be basically the same as some IPC solution (and probably
better, as msbuild seems pretty well defined / stable these days). Patches
for a CompilationDatabase implementation that just reads from msbuild would
be super-welcome :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130814/61104852/attachment.html>


More information about the cfe-dev mailing list