Distinguishing `cargo run` from `cargo build` for exporting files
⚓ Rust 📅 2025-08-24 👤 surdeus 👁️ 14I'm again at a framework where files may be contributed to the app's installation directory.
The debug_assertions constant may be used to detect cargo build --release, but I wanted some consensus on what is best to do here.
In my framework the user could do this at the Cargo manifest:
[package.metadata.fl]
files = [
{ from = "assets/**/*.webp", to = "img" }
]
This would make it so the source path ~/assets/flowers/red.webp may be read during runtime using the app://img/flowers/red.webp URL (and the actual file will be exported at that path as well).
When debugging (e.g. cargo running an app), I want to avoid exporting these files, therefore bootstrapping the application with the (from, to) entries so I do some magic when resolving app: URLs for the user. (In the HTML5 target, app: is resolved via HTTP requests, while in native targets I'd use std::fs and the executable path).
What leaves me confused is whether I detect cargo run solely through debug_assertions or if there's something more reliable to use (because, then, even a simple cargo build can't be used correctly as I'd not export files when debugging with the debug_assertions approach).
5 posts - 2 participants
🏷️ Rust_feed