Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an exploration/attempt to reorganize the bindings based on DLLs rather than only organizing everything based on the hierarchy established by the upstream metadata project. The "metadata project hierarchy" is a layer on top of an already existing grouping of functions that the OS has already established. With ideas to add filtering, making the code generator aware of this lower level organization will give more fine-grained control and dependency aware filtering mechanisms.
Here's the current idea on how to accomplish this:
New Code Generator Flow
Pass 1: Separate Functions into DLLs and associate types/constants
While generating the DLL json files, store an association between all types and the DLL's that reference them in memory. Once finished, write these associations to an extra file for pass2 to use (i.e.
types.json
).Note that "COM objects" are included in these "types". They are not associated with DLL's like functions are, but, there might be functions that come from DLL's that can accept/return COM objects. These interactions will be captured by the type associations we already established above.
Also note that the metadata project has defined special types for some constants, and we can use those types to know where these constants go. However, we may need to do some "finagling" for constants where this hasn't been done, namely, codify the patterns Microsoft has established to organize the constants and use those to find their "home".
Pass 2: Generate Zig
The Metadata Project Hierarchy
If we like, it should be easy to maintain the existing hierarchy by generating files that link to the corresponding constant/type/function in the newly organized files. This could even be an optional separate package so that new projects don't need to download this large set of aliases if they don't need them.
Filtering
To summarize the reorganization, the generator does this:
With this new organization, filtering becomes simple: