I had an idea that might alleviate the pain of this crate's compile times (#26): Once we have a code generator in Rust (#50) – which would probably be quite fast (the current one written in C# is already quite fast) – we could run the code generator via procedural macro and that procedural macro could take use statements of WinRT types/modules as input. We would then generate only those pieces of the APIs that are needed for the used functionality (and required dependencies).
Users of winrt-rust would then usually have one module/file in their project with a content like this:
winrt! {
use windows::foundation::{Uri, PropertyValue};
use windows::devices::enumeration::DeviceInformation;
use windows::devices::midi::*; // `*` could be allowed
}
... and that module becomes the "root" module for their personal stripped-down version of the generated projection sources. Which would probably compile by orders of magnitude faster.
This implies that the projections are always generated with whatever version of the metadata assemblies the user has installed. However, there's even a nice side-effect: We could add another annotation in the macro with which the user specifies the metadata assembly from which the code generator will read all the definitions. So one could integrate custom WinRT types, or request a specific version, etc.
I had an idea that might alleviate the pain of this crate's compile times (#26): Once we have a code generator in Rust (#50) – which would probably be quite fast (the current one written in C# is already quite fast) – we could run the code generator via procedural macro and that procedural macro could take
usestatements of WinRT types/modules as input. We would then generate only those pieces of the APIs that are needed for theused functionality (and required dependencies).Users of winrt-rust would then usually have one module/file in their project with a content like this:
... and that module becomes the "root" module for their personal stripped-down version of the generated projection sources. Which would probably compile by orders of magnitude faster.
This implies that the projections are always generated with whatever version of the metadata assemblies the user has installed. However, there's even a nice side-effect: We could add another annotation in the macro with which the user specifies the metadata assembly from which the code generator will read all the definitions. So one could integrate custom WinRT types, or request a specific version, etc.