<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 14, 2012, at 9:49 AM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Just some peanut gallery comments...<div><br></div><div>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.</div>
<div><br></div><div>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...</div>
<div><br><div class="gmail_quote">On Wed, Mar 14, 2012 at 5:35 AM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":2ks">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.,<br>
<br>
make CXX=clang++ CXXFLAGS="-fcompilation-database=compile_commands.json"<br>
<br>
and then, later, run a tool over compile_commands.json.</div></blockquote></div><br></div><div>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.</div>
<div><br></div><div>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. </div></blockquote><div><br></div><div>This is all fine for the vast majority of developers, who have small-to-medium projects that build on one machine.</div><br><blockquote type="cite"><div>Any DistCC setup (or similar) will immediately break this.</div></blockquote><div><br></div>Yes, we'll need something smarter for distributed builds, but it's also fine for that to require more effort to set up.</div><div><br><blockquote type="cite"><div><br></div><div>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.</div>
</blockquote><br></div><div>I think the in-clang system is important for the feature to be useful, and a scan-build like system is a nice-to-have for very large/distributed projects in the future.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><br></body></html>