e9a0ef49f9
# Objective The goal of `bevy_platform_support` is to provide a set of platform agnostic APIs, alongside platform-specific functionality. This is a high traffic crate (providing things like HashMap and Instant). Especially in light of https://github.com/bevyengine/bevy/discussions/18799, it deserves a friendlier / shorter name. Given that it hasn't had a full release yet, getting this change in before Bevy 0.16 makes sense. ## Solution - Rename `bevy_platform_support` to `bevy_platform`. |
||
|---|---|---|
| .. | ||
| library | ||
| README.md | ||
no_std Examples
This folder contains examples for how to work with no_std targets and Bevy.
Refer to each example individually for details around how it works and what features you may need to enable/disable to allow a particular target to work.
What is no_std?
no_std is a Rust term for software which doesn't rely on the standard library, std.
The typical use for no_std is in embedded software, where the device simply doesn't support the standard library.
For example, a Raspberry Pi Pico has no operating system to support threads or filesystem operations.
For these platforms, Rust has a more fundamental alternative to std, core.
A large portion of Rust's std actually just re-exports items from core, such as iterators, Result, and Option.
In addition, std also re-exports from another crate, alloc.
This crate is similar to core in that it's generally available on all platforms.
Where it differs is that its inclusion requires access to a global allocator.
Currently, Bevy relies heavily on allocation, so we consider alloc to be just as available, since without it, Bevy will not compile.