The goal is to be able to share type definitions between the std and win32 packages. The long-term plan is to update this tool to be able to generate the bindings that will be included in std. This should be as simple as keeping a list of constants/types/functions that would be set apart for inclusion in std. At the same type, all references to these types would be updated to pull them from "std".
In order to support updates to win32 that aren't necessarily in sync with std, I'll also want a way to switch between referencing std and referencing the std win32 types generated by this project. I'm not sure the best way to do this yet. Maybe std should allow this package to be overriden? I could reserve stdwin32" as a special package name thatstd` imports to get all the win32 types.
DETAILS
I think I'll define what std needs as a set of functions, then perform a first pass on the metadata to determine what types/constants it needs.
As I'm generating code, if something is moved to std, then an alias will remain in the api it appears in. This means that inter-api references will still work.
I'll start by defining a set of constants/types/functions manually to move, then get the code to be able to move those to another module, I'll start with a single win32/std.zig module for now I think.
How to override win32 bindings in std
The current idea is to allow an application to override the win32 bindings in std with the following line in the root module:
// Use the version of std code in win32
pub const stdwin32 = @import("win32").std;
zigwin32gen will generate code meant to be included in std. That being said, a user may want to use the currently generated version of this std code rather than the one shipped with their compiler. I think I can do this by checking for a pub symbol named stdwin32 in the root module.
In these examples, assume that the generated code meant for std is deployed to std/os/windows/win32.zig.
The goal is to be able to share type definitions between the
stdandwin32packages. The long-term plan is to update this tool to be able to generate the bindings that will be included instd. This should be as simple as keeping a list of constants/types/functions that would be set apart for inclusion instd. At the same type, all references to these types would be updated to pull them from"std".In order to support updates to
win32that aren't necessarily in sync withstd, I'll also want a way to switch between referencingstdand referencing thestdwin32 types generated by this project. I'm not sure the best way to do this yet. Maybestdshould allow this package to be overriden? I could reservestdwin32" as a special package name thatstd` imports to get all the win32 types.DETAILS
stdneeds as a set of functions, then perform a first pass on the metadata to determine what types/constants it needs.std, then an alias will remain in theapiit appears in. This means that inter-api references will still work.win32/std.zigmodule for now I think.How to override win32 bindings in
stdThe current idea is to allow an application to override the
win32bindings instdwith the following line in the root module:zigwin32gen will generate code meant to be included in std. That being said, a user may want to use the currently generated version of this
stdcode rather than the one shipped with their compiler. I think I can do this by checking for a pub symbol namedstdwin32in therootmodule.In these examples, assume that the generated code meant for std is deployed to
std/os/windows/win32.zig.In
std/os/windows.zig