Support new cl.exe dependency report files

[jgoshi]

In the cl.exe compiler shipped with Visual Studio 16.7 Preview 3, cl.exe will have a new switch /sourceDependencies [json file name].

Which produces a json file in the following format
{
“Version”: “1.0”
“Data”: [
{
"Source": "c:\Full\Path\To\SourceFile1.cpp",
"Includes": [
" c:\Full\Path\To\Header1.h",
" c:\Full\Path\To\Header2.h"
]
“TlbImports”: [] // #imports
“Modules” : [] // used ifcs
}
]
}

This would be an alternative to the /showIncludes flag currently used for dependency checking.

@jhasse we would like to contribute a PR for this. Does this sound like something that would be accepted?

[jgoshi]

Thank you. I'm open to suggestions for which json library we want to take a dependency on.

[jhasse]

Sounds good, although I'm not sure if going through the filesystem won't actually be slower than the current solution.

Why should the json parsing infect any of the existing code inside of ninja?

Since you're on Windows, you might try https://docs.microsoft.com/en-us/dotnet/api/system.web.script.serialization.javascriptserializer?view=netframework-4.8, but good luck coming up with the boilerplate code for calling C# from C++.

[tristanlabelle]

The Visual C++ team is also interested in this because it would fix #1766 . I'm not familiar with json parsing options for C++ but we would look for a minimalist library as much as possible when implementing this, in the spirit of the ninja project.

[digit-google]

I would argue that it is not difficult to write a simple and fast limited JSON parser in C++ for a fixed schema like this one, that could be integrated directly into Ninja, with an option to link to another library like SIMDJson for performance if this really matters (I doubt it would). As long as the exact implementation details are hidden from the rest of the Ninja source code, support for external JSON libraries could be added as a build option. Just be sure to have an extensive unit-test suite that could be checked against any implementation.

[digit-google]

I also notice that /sourceDependencies seems to generate a JSON file whose schema is not officially specified. Unlike /scanDependencies which uses standard schema P1689r3.

Anyone knows where to find a schema for /sourceDependencies then?

[cpsauer]

If useful: I think that the last time I checked these flags out they were only for module dependencies, rather than the normal header inclusion you'd need for #1766 and #613?