Add no_std support to bevy_app#16874
Conversation
| "bevy_tasks/portable-atomic", | ||
| "bevy_tasks?/portable-atomic", | ||
| "concurrent-queue/portable-atomic", | ||
| "spin/portable_atomic", |
There was a problem hiding this comment.
The changes to bevy_ecs/Cargo.toml could be split into their own PR, but for now I'm just including them here for brevity. I'm happy to split it out if anyone has any concerns.
| commands.push(PreparedCommand::new::<Self>( | ||
| cmd!( | ||
| sh, | ||
| "cargo check -p bevy_app --no-default-features --features bevy_reflect --target {target}" |
There was a problem hiding this comment.
Now that bevy_app is compatible, we can start looking into replacing/augmenting this compile_check_no_std CI task with something more robust and tangible, like a no_std example crate.
| Ok(Some(delay)) => std::thread::sleep(delay), | ||
| Ok(Some(_delay)) => { | ||
| #[cfg(feature = "std")] | ||
| std::thread::sleep(_delay); |
There was a problem hiding this comment.
Without access to std::thread::sleep, no_std apps will run as-fast-as-possible by default. This isn't ideal, but I believe a reasonable compromise.
| #[cfg(any(target_arch = "wasm32", feature = "std"))] | ||
| use bevy_utils::Instant; |
There was a problem hiding this comment.
I'm not a fan of how we bring this Instant in. I think it'd be worth considering some kind of bevy_platform_support crate which moves things like spin, portable-atomic, critical-section, wasm-time, etc. into a single spot. It'd be more focussed than bevy_utils, and possibly clean up some of the cfg(...) noise we have across Bevy.
| #[cfg(not(feature = "downcast"))] | ||
| #[doc(hidden)] | ||
| pub trait Downcast {} | ||
|
|
||
| #[cfg(not(feature = "downcast"))] | ||
| impl<T: ?Sized> Downcast for T {} |
There was a problem hiding this comment.
downcast-rs isn't compatible with portablie-atomic (though it could be with a PR I believe!), so I've included a little dummy trait so the Plugin: Downcast bound can remain.
| #[cfg(feature = "trace")] | ||
| use tracing::info_span; |
There was a problem hiding this comment.
As with bevy_ecs, I'm flattening our relationship with bevy_utils::tracing and also relying on log for non-span logging. It's already been mentioned that we should probably move things like log and tracing into workspace dependencies, but I'm just maintaining status quo for now.
| mod sub_app; | ||
| #[cfg(not(target_arch = "wasm32"))] | ||
| #[cfg(all(not(target_arch = "wasm32"), feature = "std"))] | ||
| mod terminal_ctrl_c_handler; |
There was a problem hiding this comment.
Can't use Control-C in the terminal if your platform doesn't have a terminal...or a keyboard...
|
|
||
| /// See [`App::get_added_plugins`]. | ||
| #[cfg(feature = "downcast")] | ||
| pub fn get_added_plugins<T>(&self) -> Vec<&T> |
There was a problem hiding this comment.
This is the only real consequence of losing downcast-rs support on certain no_std targets (not all!). I would like to bring feature parity regardless, but it is fairly minor IMO.
|
No serious problems here; let me know when this is ready. |
Co-Authored-By: Alice Cecile <[email protected]>
# Objective - Contributes to bevyengine#15460 ## Solution - Added the following features: - `std` (default) - `bevy_tasks` (default) - `downcast ` (default) - `portable-atomic` - `critical-section` - `downcast` and `bevy_tasks` are now optional dependencies for `bevy_app`. ## Testing - CI - Personal UEFI and Raspberry Pi Pico demo applications compile and run against this branch ## Draft Release Notes Bevy's application framework now supports `no_std` platforms. Following up on `bevy_ecs` gaining `no_std` support, `bevy_app` extends the functionality available on these targets to include the powerful `App` and `Plugin` abstractions. With this, library authors now have the option of making their plugins `no_std` compatible, or even offering plugins specifically to improve Bevy on certain embedded platforms! To start making a `no_std` compatible plugin, simply disable default features when including `bevy_app`: ```toml [dependencies] bevy_app = { version = "0.16", default-features = false } ``` We encourage library authors to do this anyway, as it can also help with compile times and binary size on all platforms. Keep an eye out for future `no_std` updates as we continue to improve the parity between `std` and `no_std`. We look forward to seeing what kinds of applications are now possible with Bevy! ## Notes - `downcast-rs` is optional as it isn't compatible with `portable-atomic`. I will investigate making a PR upstream to add support for this functionality, as it should be very straightforward. - In line with the `bevy_ecs` no-std-ification, I've added documentation to all features, and grouped them as well. - ~~Creating this PR in draft while CI runs and so I can polish before review.~~ --------- Co-authored-by: Alice Cecile <[email protected]>
# Objective - Contributes to bevyengine#15460 ## Solution - Added the following features: - `std` (default) - `bevy_tasks` (default) - `downcast ` (default) - `portable-atomic` - `critical-section` - `downcast` and `bevy_tasks` are now optional dependencies for `bevy_app`. ## Testing - CI - Personal UEFI and Raspberry Pi Pico demo applications compile and run against this branch ## Draft Release Notes Bevy's application framework now supports `no_std` platforms. Following up on `bevy_ecs` gaining `no_std` support, `bevy_app` extends the functionality available on these targets to include the powerful `App` and `Plugin` abstractions. With this, library authors now have the option of making their plugins `no_std` compatible, or even offering plugins specifically to improve Bevy on certain embedded platforms! To start making a `no_std` compatible plugin, simply disable default features when including `bevy_app`: ```toml [dependencies] bevy_app = { version = "0.16", default-features = false } ``` We encourage library authors to do this anyway, as it can also help with compile times and binary size on all platforms. Keep an eye out for future `no_std` updates as we continue to improve the parity between `std` and `no_std`. We look forward to seeing what kinds of applications are now possible with Bevy! ## Notes - `downcast-rs` is optional as it isn't compatible with `portable-atomic`. I will investigate making a PR upstream to add support for this functionality, as it should be very straightforward. - In line with the `bevy_ecs` no-std-ification, I've added documentation to all features, and grouped them as well. - ~~Creating this PR in draft while CI runs and so I can polish before review.~~ --------- Co-authored-by: Alice Cecile <[email protected]>
|
Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to bevyengine/bevy-website#1977 if you'd like to help out. |
Objective
no_stdBevy #15460Solution
std(default)bevy_tasks(default)downcast(default)portable-atomiccritical-sectiondowncastandbevy_tasksare now optional dependencies forbevy_app.Testing
Draft Release Notes
Bevy's application framework now supports
no_stdplatforms.Following up on
bevy_ecsgainingno_stdsupport,bevy_appextends the functionality available on these targets to include the powerfulAppandPluginabstractions. With this, library authors now have the option of making their pluginsno_stdcompatible, or even offering plugins specifically to improve Bevy on certain embedded platforms!To start making a
no_stdcompatible plugin, simply disable default features when includingbevy_app:We encourage library authors to do this anyway, as it can also help with compile times and binary size on all platforms.
Keep an eye out for future
no_stdupdates as we continue to improve the parity betweenstdandno_std. We look forward to seeing what kinds of applications are now possible with Bevy!Notes
downcast-rsis optional as it isn't compatible withportable-atomic. I will investigate making a PR upstream to add support for this functionality, as it should be very straightforward.bevy_ecsno-std-ification, I've added documentation to all features, and grouped them as well.Creating this PR in draft while CI runs and so I can polish before review.