Guard windows::ffi::OsStringExt
usage behind #[cfg(windows)]
for WSL and Linux support
#1860
Labels
enhancement
New feature or request
Motivation
We'd like to run - run, not cross-compile -
DirectXShaderCompiler
directly on Linux. At the same time, @riverar found a case to rundxcore
inside WSL, which is also a Linux target.The
windows
crate doesn't compile for / run on non-Windows targets currently, asstd::os::windows::ffi::OsStrExt
isn't available ontarget_os != "windows"
.A proposed fix guards all trait implementations containing
std::os::windows::ffi::OsStrExt
behind a#[cfg(windows)]
flag. If needed, followup PRs can introduce Linux-specific implementations for these conversion traits (but read on for a 32-bit wchar caveat).Drawbacks
Extra complexity for a "purely Windows-oriented" crate. We can solve that by build-testing for Linux - in addition to cross-compiling from it.
Rationale and alternatives
Impact: Not supporting
windows-rs
on Linux and WSL while at the same time deprecatingcom-rs
leaves users with no alternative for cross-platform COM bindings into libraries likeDirectXShaderCompiler
.Additional context
Prior art: #1842 (comment)
Caveat
Furthermore, non-Windows targets use 32-bit widechars instead of 16-bit:
https://en.cppreference.com/w/cpp/language/types#Character%20types:~:text=wchar_t,a%20distinct%20type.
This should be addressed in a separate issue, and seems to be trivially implementable using Rust's
char
type. This is also how https://docs.rs/widestring implements it.The text was updated successfully, but these errors were encountered: