This example shows how to use hot-reloading with bevy.
To run without hot reloading just use cargo run.
To run the example with hot-reload enabled run these two commands in parallel:
$ cargo watch -w systems -w components -x "build -p systems --features dynamic"
$ cargo run --features reloadAlternatively with a tool like runcc you can run this as a single commands: cargo runcc -c
$ cargo watch -w systems -w components -x "build -p systems --features dynamic"
$ cargo run --features reload --target-dir "target-bin"Alternatively with runcc: cargo runcc -c runcc-windows.yml
Why is this different from Linux / MacOS?
See the list of known issues in the main readme.
Bevy specific issues:
To make changes to the systems not break the type ids of components, making a components sub-crate is recommended. This way, they are a separate compilation unit. Otherwise component queries might suddenly be empty after code changes.
library files on Windows get locked while the app is running and there is a permission error when they change
On Windows, dll files like systems.dll will get locked when they are in use by a program. This is a problem for the hot-reloader as it expects those files to change. The setup provided here is careful to avoid these issues. In particular, the following can create a bevy-specific problem:
When Bevy is used with the dynamic feature (bevy = { version = "0.8.0", features = ["dynamic"] }) there will also be (in addition to systems.dll produced hot-lib-reloader) a bevy_dylib.dll. With dynamic enabled the bevy executable now loads all dlls in the target directory — even though the hot-reloader
There are two solutions:
- Do not use bevy's
dynamicfeature. This makes it work like on Linux and macOS. But the longer compile times ared reducing the usefulness of hot-reload. - Keep using
dynamicbut with two different target directories for the lib and executable. This is the the recommended solution (see usage).