You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently winapi only supports the desktop family. However for anyone who wants to make a Windows app for a family other than desktop, they will need to have access to a different set of APIs, including linking to different import libraries.
I cannot use cargo features to select which family to use as cargo features are not mutually exclusive rust-lang/cargo#2980
Furthermore, unless the user limits themselves to no_std, they will need the collaboration of libstd as well, as it depends on system functionality which may not exist in the desired family, or may link in an import library which is for the wrong family.
The text was updated successfully, but these errors were encountered:
Just brainstorming here, because I'm not very familiar with UWP... What about adding a new target to Rust for UWP apps (say, x86_64-pc-windowsapp-msvc, for example) and then treating target_os = "windows" as WINAPI_PARTITION_DESKTOP and target_os = "windowsapp" as WINAPI_PARTITION_APP?
Note that rust-lang/rust#60260 is about to be merged which adds the i686-uwp-windows-gnu and x86_64-uwp-windows-gnu targets. These have the target_vendor set to uwp, which can be easily filtered on by cfg attributes.
Currently winapi only supports the desktop family. However for anyone who wants to make a Windows app for a family other than desktop, they will need to have access to a different set of APIs, including linking to different import libraries.
I cannot use cargo features to select which family to use as cargo features are not mutually exclusive rust-lang/cargo#2980
Furthermore, unless the user limits themselves to no_std, they will need the collaboration of libstd as well, as it depends on system functionality which may not exist in the desired family, or may link in an import library which is for the wrong family.
The text was updated successfully, but these errors were encountered: