[cfe-commits] [PATCH] Implements support to run standalone tools

[Chandler Carruth]

Just some peanut gallery comments...

We definitely need to support non CMake users -- the cmake stuff was really
only a "demo" use case, not intended to be specific. We're working with
Eclipse and the Chromium build system to grow support as well.

I had always planned for support of configure/make builds to take the form
of something not unlike scan-build, which analyzes the make run, and writes
the database. That said, your solution is quite a bit simpler...

On Wed, Mar 14, 2012 at 5:35 AM, Douglas Gregor <dgregor at apple.com> wrote:

> Now, to actually make tooling useful to non-CMake users, we'd want to make
> it possible to create a JSON compilation database without involving CMake
> at all. I suggest that we add a Clang command-line flag
> "-fcompilation-database=<filename>" and have the driver update <filename>
> with each compilation command it is invoked with. That way, one could do a
> normal project build with, e.g.,
>
>        make CXX=clang++
> CXXFLAGS="-fcompilation-database=compile_commands.json"
>
> and then, later, run a tool over compile_commands.json.
>

I like this, a lot. My worry goes beyond Manuel's though -- I don't think
this is enough. He raised the concern of how do we synchronize the writes,
and the classical way of doing that is with POSIX file locks (flock). That
should functionally work Just Fine.

However, for large builds on machine with lots of cores, flock is likely to
be way too expensive for the regular developer to want to add... What's
worse, it requires the build to take place on a single machine. Any DistCC
setup (or similar) will immediately break this.


That said the scan-build is a PITA for projects with small builds. Maybe
the right solution is *both* -- support for an in-clang system, and a
scan-build system... Unsure, just wanted to throw out the things I'd been
thinking about so you an Manuel can hash them out properly.

Thanks again for reviewing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120314/a285b8f4/attachment.html>