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
Replace unimplemented! panics with conditional #[link] attribute for WSL/Linux support
The `#[cfg]` structure is verbose and not needed for cross-compilation
(where `target_os = "windows"` anyway). Furthermore, the
`unimplemented!("Unsupported target OS")` panic prevents using all but
the most basic features windows-rs provides on non-Windows systems.
Use-cases relying on linking external functions include calling `dxcore`
from WSL and `DirectXShaderCompiler` from Linux, both using a COM
interface.
By removing this `#[cfg]` and `unimplemented!()` panic altogether
`windows`, just like `windows-sys`, now unconditionally link using
`-lwindows`. This allows crates compiling on non-Windows targets to
provide their own fallbacks for needed functions. Any required but
missing symbol becomes a linker error rather than a runtime panic.
However, such linking may not be desired or complicated to set up, and
doesn't prevent the `tool_*` applications (needed to propagate `bindgen`
changes in this PR to the final codebase, while working from a Linux
environment) through the `metadata` -> `windows-sys` crate from linking
against a `-lwindows` library (and failing).
For this reason a `cfg_attr` with `windows` predicate has been chosen:
`link(name = "windows")` will be enabled on `target_os = "windows"`
exclusively.
The guard is applied to `windows-sys` which previously didn't have any
guarding at all (once again confirming that there's no impact on
cross-compiling) to unblock `tool_*` usage on non-Windows systems.
Users are able to provide fallbacks on their own within their consumer
crate through a simple:
#[no_mangle]
pub extern "system" fn SysStringLen(..) -> ...;
for example, without having to resort to compiling that inside a
separate crate that emits a static library or shared object on the
search path. This is however still possible, though.
There are a few more issues to work out before this crate can _run_ on
Linux and WSL, which have to be fleshed out before we can officially
(build-)test this use-case in CI.
0 commit comments