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

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.