PhysicsLayer import crate based on which crate (2d or 3d) is being used#601
Conversation
|
I switched to nighly to get the warning (it's not on stable Rust yet, which is why I haven't noticed it before). I'm still getting it in
I assume the changes here fixed the warnings for you though? The fix itself makes sense to me, so I'd be fine merging this if it works for other people. It's just strange that I'm still getting it with this PR |
|
I simplified the approach and created a demo project here: https://github.com/ironpeak/avian-pr-601-demo There is a caveat with this change, it assumes that the correct PhysicsLayer is in scope so a fully qualified derive would fail e.g. #[derive(avian3d::prelude::PhysicsLayer, Default)]
pub enum GameLayer {
#[default]
Wall,
Player,
Enemy,
}If that is a problem I can rework it so that it supports both, but I liked this simplified implementation. |
Jondolf
left a comment
There was a problem hiding this comment.
I think this approach should be fine. Thanks!
I have published a 0.2.1 patch for avian_derive with these changes now, so running cargo update for apps using Avian 0.2 should hopefully update it and fix the warning.
Objective
I've been getting warnings in my project when using the PhysicsLayer derive enum, because it's generating code that is using the feature flags
2dand3d. Since the code is procedurally generated within my game project it is checking for these features in my project rather then picking based on which library is being used (avian2d or avian3d).Solution
Add 2 feature flags for
avian_derive(2dand3d). Use the feature flag when importingavian_deriveinavian2dandavian3d. Move the feature flag check out of theqoute!macro so that it is checked withinavian_deriverather then the consuming project.Changelog
Adds 2 feature flags to
avian_derivewhich should be setup correctly for bothavian2dandavian3d.Migration Guide
N/A