<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 17, 2013 at 9:44 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We have done similar things before internally, but considered it more to be a hack ;)</div><div><br></div><div>I think the direction that we want to go to is to have an option in clang to append to a compilation database while running - that way, no post-processing step is required, which again needs to be somehow put into the build flow. The only part missing is somebody with enough time on their hands for whom this is high enough priority.</div>
</div></div></div></blockquote><div><br></div><div>Wouldn't this approach (appending to a compilation database) have issues with filesystem contention and/or write atomicity in multicore/distributed builds (without involving a "real database" for the database storage)? Also, wouldn't a post-processing step be needed in order to remove outdated entries appended from a previous incremental build (consider: `make; <rename some file in the project>; make`)?</div>
<div><br></div><div>The approach I proposed has two extremely desirable properties that I think would be hard to achieve with an approach that carries the information in an external "side channel", as in the approach you suggested:</div>
<div>1. The compilation database info is always up to date as long as the build products are up to date, since the information follows the "causal chain" leading to the final programs/libraries. </div><div>2. It works "everywhere clang does" since it makes no assumptions about build systems, filesystems, or anything else; the data is carried along a datapath that already works (namely, that information emitted by the compiler will end up in build products).</div>
<div><br></div><div>Also, the format of the embedded entry could be streamlined to make it utterly trivial to extract, e.g. a simple string "@ClangCompilationDatabaseEntryMD5JSON<hex md5sum of $JSON>$JSON", and then you could reliably extract the compdb entries with a single linear scan of arbitrary binary files; with that it seems like it would be feasible for most use cases (possibly adding an optional caching step) to have clang tools directly accept binaries containing such data as the compilation database itself!</div>
<div><br></div><div>-- Sean Silva</div></div></div></div>