Wgpu: Make libx11 optional on Vulkan

Created on 28 May 2020  路  2Comments  路  Source: gfx-rs/wgpu

Description

wgpu-core currently hardcodes the x11 feature on the gfx-backend-vulkan crate for Unix platforms. This has the effect that building on a system with Wayland still requires libx11 development libraries to be installed.

https://github.com/gfx-rs/wgpu/blob/4c136418ff20ed52f4c56b6af3ec419d356a9ac4/wgpu-core/Cargo.toml#L58-L59

Repro steps

Build wgpu-core on a Linux system without libx11. E.g. the clux/muslrust Docker image.

$ docker image pull clux/muslrust:latest
$ docker run -it --rm clux/muslrust:latest

root@8d5e3f85d364:/volume# git clone https://github.com/gfx-rs/wgpu.git
root@8d5e3f85d364:/volume# cd wgpu/
root@8d5e3f85d364:/volume/wgpu# cargo build --package wgpu-core
[...snip...]
error: failed to run custom build command for `x11 v2.18.2`

Caused by:
  process didn't exit successfully: `/volume/wgpu/target/debug/build/x11-28c43b6fae26f5d7/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Failure { command: "\"pkg-config\" \"--static\" \"--libs\" \"--cflags\" \"x11\" \"x11 >= 1.4.99.1\"", output: Output { status: ExitStatus(ExitStatus(256)), stdout: "", stderr: "Package x11 was not found in the pkg-config search path.\nPerhaps you should add the directory containing `x11.pc\'\nto the PKG_CONFIG_PATH environment variable\nPackage \'x11\', required by \'world\', not found\nPackage \'x11\', required by \'world\', not found\n" } }', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-2.18.2/build.rs:36:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

warning: build failed, waiting for other jobs to finish...
error: build failed

Expected vs observed behavior

I believe this dependency can be made optional with a feature flag.

Side note: On the v0.5 branch, wgpu-native has a hardcoded dependency on libx11:

https://github.com/gfx-rs/wgpu/blob/eeda6dcdfd0bdb52c97217e61e2bb195e1b03a4f/wgpu-native/src/device.rs#L50-L56

I don't see any similar limitations on master, so this should be trivial? Ah, I found the new home of wgpu-native, and it still has a hard dependency on libx11. The good news is this crate is no longer in the pure-Rust dependency tree, and it can be handled separately.

Extra materials

Originally reported in https://github.com/parasyte/pixels/issues/83

Platform

Linux/Wayland

bug

Most helpful comment

I guess using the x11 types in gfx doesn't really give us much benefit and the x11 dependency is heavyweight. We've also been trying to avoid using features for backends/environments so features wouldn't be ideal here.

Maybe we could drop the x11 dependency from gfx and just use type aliases/raw types for surface creation? e.g. in raw-window-handle the raw types are located at https://github.com/rust-windowing/raw-window-handle/blob/044e464bb4eaca3c215028199223ecc13831d85d/src/unix.rs#L16-L19). raw-window-handle should work well for most users so using raw types wouldn't be very common anyway.

All 2 comments

I guess using the x11 types in gfx doesn't really give us much benefit and the x11 dependency is heavyweight. We've also been trying to avoid using features for backends/environments so features wouldn't be ideal here.

Maybe we could drop the x11 dependency from gfx and just use type aliases/raw types for surface creation? e.g. in raw-window-handle the raw types are located at https://github.com/rust-windowing/raw-window-handle/blob/044e464bb4eaca3c215028199223ecc13831d85d/src/unix.rs#L16-L19). raw-window-handle should work well for most users so using raw types wouldn't be very common anyway.

We can safely remove the dependency requirement and leave it up to the user to enable. I.e. the user may have something like this (in addition to depending on wgpu):

[target.'cfg(all(unix, not(target_os = "ios"), not(target_os = "macos")))'.dependencies]
gfx-backend-vulkan = { version = "0.5", features = ["x11"] }
Was this page helpful?
0 / 5 - 0 ratings

Related issues

msiglreith picture msiglreith  路  4Comments

kvark picture kvark  路  4Comments

rukai picture rukai  路  3Comments

rukai picture rukai  路  5Comments

kvark picture kvark  路  4Comments