Open wucke13 opened 1 year ago
I've seen the issue, but I'm currently hesitant to merge it before I don't have static linking implemented as the default option (so that people don't have to use Azul.dll
in Rust executables anymore).
I think I also wanted to remove xcb because I wanted Azul to be dependency-free on Linux.
Description
This project ships a
Cargo.lock
(which is good, considering that it also is meant to be build-able as binary to provide theazul-dll
), which unfortunately contains a very old version ofxcb
. This very old version ofxcb
generates code into the cargo-vendor-dir, which makes it impossible to compile azul in the nix ecosystem, since the cargo-vendor-dir resides in the read-only nix store, causing any attempt to write a file to it to fail. Generally I think its also considered just wrong to write to the cargo vendor dir, there is an environment variable for where to generate artifacts (OUT
I think?).Edit: This dependency is introduced via
azul-desktop/clipboard2
, which hasn't been touched in the last 4 years and pinpointsx11-clipboard
to version0.3.0-alpha.1
, which again is 4 years old and has reached version0.7.0
by now. I think it would be good to update some of the transitive dependencies of the stuff involved.