Bevy and dependencies recompile when client code changed

help
1

I'm playing around with Bevy. Whenever I modify and recompile the client code, all of the following also get recompiled, every single time :

   Compiling alsa-sys v0.3.1
   Compiling x11-dl v2.21.0
   Compiling libudev-sys v0.1.4
   Compiling gilrs-core v0.5.11
   Compiling alsa v0.9.0
   Compiling gilrs v0.10.6
   Compiling bevy_gilrs v0.12.1
   Compiling cpal v0.15.3
   Compiling rodio v0.17.3
   Compiling bevy_audio v0.12.1
   Compiling winit v0.28.7
   Compiling accesskit_winit v0.15.0
   Compiling bevy_winit v0.12.1
   Compiling bevy_internal v0.12.1
   Compiling bevy v0.12.1
   Compiling bevy-trial v0.1.0 (/tmp/bevy-workshop)

the last one being my own code.

I trust that this is not supposed to happen. What might be causing all this recomplilation? How should I go about eliminating it?

Here is the Cargo.toml being used:

[package]
name = "bevy-trial"
version = "0.1.0"
edition = "2021"

[dependencies]
bevy = "0.12.1"
rand = "0.8.5"

# Enable a small amount of optimization in debug mode
[profile.dev]
opt-level = 1

# Enable high optimizations for dependencies (including Bevy), but not for our code:
[profile.dev.package."*"]
opt-level = 3
2

See the Enable Fast Compiles section of bevy docs. Notably, enable bevy dynamic_linking flag to avoid recompilation in development.

As for why, you can use cargo build --verbose which is supposed to tell you why it's recompiling stuff, but given that it's a dependency tree, alsa-sys in this case causes everything that's depending on it to rebuild. That happens because it's got a build.rs script (like most sys crates) that generates files, which invalidates cache and triggers recompilation (even though the environment is otherwise identical between runs).

1 Like
3

Sorry, I should have mentioned: been there, done that, got the T-shirt, but it still recompiles the same stuff.

I'll try it again (for at least the 3rd time) in case I messed something up before ...

Edit: Could it be related to rust-analyzer recompiling things without dynamic linking and throwing a spanner in the works? I noticed that sometimes (always? usually?) I get

Blocking waiting for file lock on build directory

when recompiling. I disabled rust-analyzer, and this block seems to have disappeared and now only my code gets recompiled.

4

Yes, this is what causes rebuilds in most of the projects I work on. You can attempt to configure RA to use the same setup (target, environment variables, etc.) as your CLI builds, but I have only very rarely got it to work consistently, and it's always a per-project pain to manage.

2 Likes
5

It seems that rust-analyzer (and other tools like bacon) were the problem.

By using

bevy = { version = "0.12.1", features = ["dynamic_linking"] }

in Cargo.toml (rather than than specifying --features bevy/dynamic_linking as an option to cargo run) and then restarting rust-analyzer and/or bacon[1], the problem goes away.

  1. actually, bacon seems to notice that Cargo.toml has changed, and reconfigures itself ↩ī¸Ž

1 Like
6

I guess you're referring to some CLI options which are not configured in Cargo.toml? In this case setting the option in Cargo.toml seems to have fixed it for RA and bacon. Or am I missing something?

7

Assuming you're using VSCode/fork, you can configure RA flags in the settings (per workspace), and add --features bevy/dynamic_linking there as well.
But yeah, I intended to tell you to add the feature to the Cargo.toml, I default to that (as opposed to arguments) so I assumed you would as well - sorry for confusion.

The workspace approach is good if you're running the project through a CI/CD and want to keep some flags committed to the repo (though .vsconfig/* files) but only apply to development.

8

No. Doom Emacs.

I did try both the CLI approach and the Cargo.toml one (even before your suggestion) but as the already-running RA didn't pick up the changes in the manifest, the two approaches appeared equally broken. That is to say, you didn't cause any confusion, I was already thoroughly confused :slight_smile:

And your suggestion gave me confidence that that particular bit of documentation was related to the effect I was looking for, which gave me the motivation to poke around it a bit more. So it was very helpful. Thanks.

1 Like
9

It's probably not relevant, but I can clarify the specific case I am referring to. Some build scripts require specific environment variables, not cargo config or CLI args. Windows has a very strange way to handle env vars when using a non-standard shell. I use bash (from git-for-windows) and the env is configured just like normal with ~/.bashrc (it doesn't seem to inherit the user's environment for some reason). For portability (I use the same bashrc on WSL and macOS) all paths use / path separators.

This latter point directly conflicts with the Windows-preferred path separator used in the Windows environment. When a build script relies on an environment variable, it usually also requires it to remain consistent, or it will force a rebuild. One example I hit was with LIBCLANG_PATH for bindgen, where I had different values for the path set in bash vs. my IDE.

Easy to correct this kind of mistake once you become aware of it, but it was a lot of debugging with cargo build -vvvvv up front. I switched to full-blown Windows paths in my bashrc for variables that need to be consistent with the Windows user environment. C:\Users\me\projects instead of Windows-bashisms like /c/Users/me/projects.

Anyway, it's not unheard of to run your shell and IDE with different environments even on Linux, so this PSA might still be useful for others. It is not a problem specific to Windows craziness.

1 Like
10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.