Development and release builds

The game library is built with Cargo’s dev profile by default, and with the release profile when --release is given. The two want opposite things, and the projects Rusteal creates set them up for that in Rust/Cargo.toml, the only place Cargo reads profiles from (in the game crate’s own Cargo.toml they are ignored with a warning).

dev: iterating

rusteal build

Rebuilding after a change must be fast, and the game must still run well in the editor:

• your game crate, the one that changes, is barely optimized, so it compiles in about a second;
• the Rusteal crates and the generated bindings, which compile once, are fully optimized;
• your crate has full debug info, for the debugger; the dependencies and the bindings keep only file and line, enough for backtraces, so the library stays small enough to reload quickly.

release: shipping

rusteal build --release

The fastest library possible, however long it takes to build: one codegen unit per crate and link-time optimization across crates, which also drops the parts of the bindings the game does not use. rusteal package always builds this profile.

Tuning

The profiles are yours to change, in Rust/Cargo.toml. The optimization levels follow Bevy’s recommendations for game projects:

[profile.dev]
opt-level = 1

[profile.dev.package."*"]
opt-level = 3
debug = "line-tables-only"

[profile.dev.package.bindings]
opt-level = 3
debug = "line-tables-only"

[profile.release]
codegen-units = 1
lto = "thin"

Every crates.io dependency you add is covered by "*": optimized, with file and line only. To step into one of them in the debugger, give it full debug info alone:

[profile.dev.package.rapier3d]
debug = true

Keep the bindings at line-tables-only: with full debug info, the library grows past a hundred megabytes, and every hot reload loads it again.