JSON-escape strings

[d3m3t3r]

Add JSON-escaping for string values (e.g. arguments and filenames) in the output.

[i-ky]

At the moment to use basset one needs to run a clean build from zero. But it would be nice to add support for partial builds, when intercepted commands are appended to the existing compile_commands.json instead of overwriting it completely. This will require not just writing, but also reading JSON and will likely require a proper JSON library. Escaping can then also be done using JSON library.

I believe this was my thought process when I decided to completely ignore the need to escape strings in JSON. So maybe instead of implementing our own JSON escaping implementation you can help me pick a good JSON library to use?

[d3m3t3r]

I'm trying to implement support for partial builds (with https://github.com/nlohmann/json for JSON handling) and as you recognized it will make this PR obsolete.

BTW, when the new command replaces an existing command(-s?) in the database? Never? Meaning, new commands are always appended except for exact duplicates (e.g. same "filename", "directory" and "arguments")?

[i-ky]

I'm trying to implement support for partial builds (with https://github.com/nlohmann/json for JSON handling) and as you recognized it will make this PR obsolete.

This sounds great! 🤩

BTW, when the new command replaces an existing command(-s?) in the database? Never? Meaning, new commands are always appended except for exact duplicates (e.g. same "filename", "directory" and "arguments")?

This is a very good question. On one hand, clangd and probably other consumers of compile_commands.json only support one compilation command per file, so for them only replacing would make sense. On the other hand, compile_commands.json format itself and probably some consumers (e.g. run-clang-tidy) support multiple compilation commands per file, for them appending will make sense. I think a good enough approach would be to mimic what Bear does.

Actually, speaking of Bear... It is an option to "simply" integrate basset with bear as a low-level intercept mechanism, this way all high level functionality (like support for partial builds) will be automatically provided by bear. basset will focus entirely on intercepting the commands. See the relevant discussion.

[i-ky]

@d3m3t3r, thank you for your contribution!

[d3m3t3r]

This is what I come up for the support of incremental update so far: https://github.com/d3m3t3r/basset/tree/incremental-update

[i-ky]

@d3m3t3r, don't be shy! Feel free to create a PR. If it is still "work in progress", you can mark it as draft. In any case it will serve as advertisement of your work and upcoming feature in basset.