Dont generate the bindings in src/bindings.rs

[pragmatrix]

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.

[pragmatrix]

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.

[pragmatrix]

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

[pragmatrix]

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 the src/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 to aarch64-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 (Handle include!(concat!(env!("OUT_DIR"), "/bindings.rs")); intellij-rust/intellij-rust#1908).

[ghost]

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?

[pragmatrix]

@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.