57086d4416
# Objective Since we are planning to remove the need to derive both `Event` and `EntityEvent` in 0.17 either way, I'm choosing to do the easy thing in this PR so we can get the churn out of the way early. Context from [discord](https://discordapp.com/channels/691052431525675048/1383928409784193024/1393463673137401946). Related to, and will conflict slightly with #20101. ## Solution - Derive `Event` as part of the `EntityEvent` derive - Remove any `Event` derives that were made unnecessary - Update release notes |
||
|---|---|---|
| .. | ||
| 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.