Implmenting a YAML generator from the emitted bitcode summary of declarations. Emits one YAML file per declaration information.
For a more detailed overview of the tool, see the design document on the mailing list: RFC: clang-doc proposal
juliehockett on Feb 22 2018, 6:20 PM.Authored by
Please run Clang-format and Clang-tidy modernize over new code.
I'm a bit late on this, but I'd say that YAML is usually not a 'final' format. What would be the use-cases for this? And if is meant as an alternative intermediate format, why not instead of having one big file, have one file per input file? Just wondering what the particular motivation for that could be
(Don't mind the previous and inline comment, it was old and I never got to submit it. Differential doesn't let me remove it unfortunately)
The idea is that it's a generally-consumable output format, and so could be interpreted by external software fairly trivially. The bitsream format is compact and good for things that will live entirely in the clang-doc tool, but is harder to deal with outside that scope. YAML bridges that gap.
I haven't thought too much about splitting it up, but it might make sense, given that the one file could get very large. By file might work--let me play with it a bit to see what makes the most sense.
That's what I expected :).
The primary advantage of one file per output to us was granularity. That allows you to do incremental builds and distribute them at this stage (locally over multiple cores, but also remotely if need be).
Updating for better integration with MR framework, the generator now takes in an info and an output stream and emits the YAML to that stream. Each info is emitted to its own YAML file.