> 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.
This was my line of thought as well. Since the C++ stdlib unfortunately doesn't have JSON support, what do you think about a simpler, more plaintext-y compilation database (PlaintextCompilationDatabase?); it seems like that might be a win since it is simpler to output. For example, the format would just be /path/to/dir/ clang++ foo.cpp foo.cpp <empty line> Just a mirror of the JSON one, but with a format easier to output (god forbid there's a newline in one of the command lines or filenames). On the other hand, throwing together a simple "good-enough" JSON writer isn't *too* difficult; nonetheless, for tools written in C/C++, this could lower the bar to entry. Do you know what CMake currently does? Does it have its own mini JSON writer? --Sean Silva On Wed, Jul 18, 2012 at 2:54 PM, Chandler Carruth <[email protected]> wrote: > On Wed, Jul 18, 2012 at 2:45 PM, Sean Silva <[email protected]> wrote: >> >> I was looking at adding compilation database support for ninja build >> files. However, I ran into the problem that it basically amounted to >> rewriting the entire ninja build file parser that is already >> implemented inside of ninja. As such, it seems like the very nature of >> compilation databases is something that needs to be output by the tool >> configuring/doing the build. >> >> Is your thought with this that, for example, ninja would provide a >> compilation database plugin reusing its own parser? > > > 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. > > 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
