Potentially provide cleaner interop layer using SharpGen

[Oceanswave]

https://github.com/jkoritzinsky/SharpGenTools

Could reduce the interop layer generation steps and provide a cleaner interop layer to boot. If anything, we should examine the output to refine what interop types are exposed.

[Oceanswave]

Obtain CastXML pre-built binary from: https://github.com/CastXML/CastXMLSuperbuild https://midas3.kitware.com/midas/folder/13152

Invoke with: C:\Projects\castxml\bin>castxml --castxml-gccxml -x c++ -std=c++11 -fmsc-version=1900 -fms-extensions -fms-compatibility -Wno-microsoft-enum-value -Wmacro-redefined -Wno-invalid-token-paste -Wno-ignored-attributes -Wno-pragma-once-outside-header -o output.xml c:\Projects\chakracore\lib\jsrt\ChakraCore.h -E -dD -C

[Oceanswave]

Mapping file examples are scattered throughout SharpDX -- assuming the schema hasn't changed. For ex: https://github.com/sharpdx/SharpDX/blob/8b0e1a86b428dc1acdef6ee45f34c93f2de9ea0e/Source/SharpDX.Direct3D11/Mapping.xml

[Oceanswave]

Can be invoked in console app and config provided imperatively -- see test project https://github.com/jkoritzinsky/SharpGenTools/tree/master/SharpGen.E2ETests

[Oceanswave]

https://github.com/BaristaLabs/ChakraCoreSharpGen

[Oceanswave]

See https://github.com/sharpdx/SharpDX/blob/8dc1f64a9424c6b0dc8b9009f70e144ded03f1d7/Source/SharpDX/Mapping-core.xml for base mappings

[Oceanswave]

Given the output currently seen, I'm most excited for the raw generation of the -out.xml file, rather than the actual generation itself, which uses unsafe code. Perhaps there's a way to configure this to use SafeHandles instead, but it would be great to rewrite the generator with the -out.xml file as its entry point, and use the handlebars based generation process.

[Oceanswave]

Comments are the issue -- -C allows for preprocessing to include comments, but those comments don't get into the final.

It appears that the the only functionality that uses the pre-processed file coming from castxml is the MacroManager that picks up the files - The comments in the pre-processed file don't appear to be well structured either, so getting them associated with codegen items is going to be interesting.

[Oceanswave]

Going to keep this open, the pros of this are that CastXML, which is part of a standard ubuntu distro, is well maintained and widespread. The cons are that I'll need to write a new parser to pull in comments from the pre-process output and correlate when generating the class files. While this will be some work, the good is that the generator can be a similar Handlebars-based declarative template approach, rather than an imperative approach that SharpDX/SharpGen uses.

As far as "cleaner" there's not really any magic that's happening here that will provide a more "solid" interop layer than what we already have. The mappings in SharpDX aren't 1:1 (unsigned int to int32, for instance) and so we're actually doing better already. CastXML does have a better representation of the C++ types, however, so that eventually can make things better.

[Oceanswave]

Some discussion here indicates that CastXML has a 'doc provider' that will make it easier to get at the docs (comment indicates the built-in MsdnProvider as a reference)

Might be progress.

[Oceanswave]

new plan. Use CastXML to parse headers. Create custom parser and output desired custom XML for ingestion into the existing code file generation. Will need to create custom method to pull xml code comments from header files using regex and line number from CastXML output.

[Oceanswave]

The new mechanism to generate the ChakraExternDefinitions.xml using CastXml is available here: https://github.com/BaristaLabs/ChakraCoreCastXml