Dont generate the bindings in src/bindings.rs
pragmatrix opened this issue · comments
This messes up compilation dependency tracking and also - I think - produces stale IDE results in dependent projects when cargo check
is used and INIT_SKIA
is not set, because the cargo project is always out of date after the bindings are regenerated. I also assume that's why the check for INIT_SKIA
exists in the build.rs
script.
I've tried the following:
- Write the bindings to
OUT_DIR
and include them like suggested in https://rust-lang.github.io/rust-bindgen/tutorial-4.html
Result: Works, no stale results, but IDE (CLion) (and probably others) does not pick up the binding's symbols, probably because of the macro use.
Next step is to patch mtime of the generated file src/bindings.rs
in the build.rs
script. This can only be a temporary solution primarily targeted for IDE support, because AFAIK we can not write in the src
directory for cargo package generation anyway.
Update: The stale IDE results were caused by IntelliJs Rust plugin when cargo check
was enabled, and were fixed in a recent nightly. Also the macro support was improved, so may be we can take another look at using include!
here or just wait until rust-analyzer is in a reasonable stable state, because although I got used to CLion, personally I would prefer to use VSCode again.
Anyway, if we want to suppport different feature sets for the binding generation, putting bindings.rs
into the src/
directory will produce problems for dependent projects.
To support a different skia configuration, I also started to experiment to put the complete skia / ninja output into OUT_DIR
, which works rather fine and cargo clean
does now what it's supposed to do.
Closing this because the original problem does not appear anymore. We may need to takle this problem again if we want to support multiple features.
I'm reopening this, because Rust / Cargo release version 1.33 might affect us: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#cargo
This issue seems to stick with us until it gets fixed properly. Currently, there are two problems caused by it:
- The crate verfication of skia-bindings fails, because it detects that
skia-bindings/src/bindings.rs
was modified in the build process. - A
cargo build
with a different target causes skia-bindings to be recompiled, but not thesrc/bindings.rs
file to be regenerated which might cause linker errors. This can be reproduced by building a darwin target on a macOS machine and switching toaarch64-linux-android
after that.
Blocked by:
- Support for resolving symbols through
include!(concat!(env!("OUT_DIR"), "/bindings.rs"));
- in rust-analyzer.
- in CLion / IntelliJ/Rust (intellij-rust/intellij-rust#1908).
Is this in any way related to how skia-bindings
redownloads Skia every time I change a compiler flag? If not, should I open a separate issue for that?
@JackRedstonia Sounds unrelated, every time the build scripts runs from within a crate, binaries are downloaded. I suppose that there should be a test if matching binaries already exist.