On Wed, Jul 18, 2012 at 2:45 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank" class="cremed">silvas@purdue.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was looking at adding compilation database support for ninja build<br>
files. However, I ran into the problem that it basically amounted to<br>
rewriting the entire ninja build file parser that is already<br>
implemented inside of ninja. As such, it seems like the very nature of<br>
compilation databases is something that needs to be output by the tool<br>
configuring/doing the build.<br>
<br>
Is your thought with this that, for example, ninja would provide a<br>
compilation database plugin reusing its own parser?<br></blockquote><div><br></div><div>For ninja in particular, I have long thought that the correct approach is to write something which can convert 'ninja -t commands' into the JSON format, or to build a tool for writing the JSON database directly into ninja. Then CMake (or anything else that generates the build file) can inject targets to automatically generate and update this file. This includes re-building generated source files as necessary.</div>
<div><br></div><div>I think for OSS build systems and systems that are largely command-line-driven like ninja, the file output and interchange system is a much better alternative. The plugin support I think is mostly useful for stateful build systems which may really need to implement the database using custom logic.</div>
</div></div>