[cfe-dev] [cfe-commits] Design proposal: Add custom compilation database formats as plugins

[Sean Silva]

> 3) It is *incredibly* easy to write a minimal JSON writer that only supports the features we need.

Ah, ok, I seem to have overestimated how difficult/annoying this would
be to write.

> We can easily place a copy of the code into LLVM or re-license it however it helps.

This might be good, to help keep things consistent. Are you thinking
something with a role like ninja's ninja_syntax.py?

--Sean Silva

On Wed, Jul 18, 2012 at 3:15 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Wed, Jul 18, 2012 at 3:11 PM, Sean Silva <silvas at purdue.edu> wrote:
>>
>> > 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?
>
>
> We didn't go with the plaintext route for three important reasons:
>
> 1) Filenames do have whitespace in them. The format should be robust against
> that.
> 2) Many other tools and languages should have a minimal barrier to read
> them. An existing format eases this.
> 3) It is *incredibly* easy to write a minimal JSON writer that only supports
> the features we need.
>
> Manuel contributed the CMake support for the JSON database, and it includes
> just such a trivial JSON writer. =] We can easily place a copy of the code
> into LLVM or re-license it however it helps.
>
> That said, the latest version of CMake already has support for JSON + Ninja
> -- we didn't contribute it, so I don't know what strategy they followed, but
> you should look at that and talk to the ninja and CMake developers before
> going too far here.