You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What problem does this solve or what need does it fill?
I have been trying to get bits and pieces of Bevy building for an unusual target platform (armv6k-nintendo-3ds), and to my surprise bevy_ecs almost compiles already!
With Rust 1.60.0 the #[cfg(target_has_atomic = "64")] flag has just been stabilized: rust-lang/rust#93824. I propose using this to conditionally compile using AtomicI32 on platforms that do not support 64-bit atomics.
I'm not sure if there might be any further-reaching consequences of such a change, but this platform is already not supported, so it seems like adding support in this way would still be "experimental" or possibly unstable, but still an improvement on the status quo. Existing platforms' implementation would not be impacted.
What alternative(s) have you considered?
No action; effectively require using a fork for platforms without atomic i64 support.
Additional context
I already have a local change with which I have successfully built for armv6k-nintendo-3ds – I'm happy to open a PR if this proposed solution is accepted.
The text was updated successfully, but these errors were encountered:
…evyengine#4452)
# Objective
- Fixesbevyengine#4451
## Solution
- Conditionally compile entity ID cursor as `AtomicI32` when compiling on a platform that does not support 64-bit atomics.
- This effectively raises the MSRV to 1.60 as it uses a `#[cfg]` that was only just stabilized there. (should this be noted in changelog?)
---
## Changelog
- Added `bevy_ecs` support for platforms without 64-bit atomic ints
## Migration Guide
N/A
…evyengine#4452)
# Objective
- Fixesbevyengine#4451
## Solution
- Conditionally compile entity ID cursor as `AtomicI32` when compiling on a platform that does not support 64-bit atomics.
- This effectively raises the MSRV to 1.60 as it uses a `#[cfg]` that was only just stabilized there. (should this be noted in changelog?)
---
## Changelog
- Added `bevy_ecs` support for platforms without 64-bit atomic ints
## Migration Guide
N/A
ItsDoot
pushed a commit
to ItsDoot/bevy
that referenced
this issue
Feb 1, 2023
…evyengine#4452)
# Objective
- Fixesbevyengine#4451
## Solution
- Conditionally compile entity ID cursor as `AtomicI32` when compiling on a platform that does not support 64-bit atomics.
- This effectively raises the MSRV to 1.60 as it uses a `#[cfg]` that was only just stabilized there. (should this be noted in changelog?)
---
## Changelog
- Added `bevy_ecs` support for platforms without 64-bit atomic ints
## Migration Guide
N/A
What problem does this solve or what need does it fill?
I have been trying to get bits and pieces of Bevy building for an unusual target platform (
armv6k-nintendo-3ds
), and to my surprisebevy_ecs
almost compiles already!The only issue I ran into was in https://github.com/bevyengine/bevy/blob/main/crates/bevy_ecs/src/entity/mod.rs#L35 – since the platform does not have atomic load/stores for
i64
, there is noAtomicI64
available for import. I imagine that some other 32-bit platforms may also run into this problem, but have probably not been the focus of the project thus far.What solution would you like?
With Rust 1.60.0 the
#[cfg(target_has_atomic = "64")]
flag has just been stabilized: rust-lang/rust#93824. I propose using this to conditionally compile usingAtomicI32
on platforms that do not support 64-bit atomics.I'm not sure if there might be any further-reaching consequences of such a change, but this platform is already not supported, so it seems like adding support in this way would still be "experimental" or possibly unstable, but still an improvement on the status quo. Existing platforms' implementation would not be impacted.
What alternative(s) have you considered?
No action; effectively require using a fork for platforms without atomic i64 support.
Additional context
I already have a local change with which I have successfully built for
armv6k-nintendo-3ds
– I'm happy to open a PR if this proposed solution is accepted.The text was updated successfully, but these errors were encountered: