PhysicsLayer import crate based on which crate (2d or 3d) is being used

[ironpeak]

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 2d and 3d. 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 (2d and 3d). Use the feature flag when importing avian_derive in avian2d and avian3d. Move the feature flag check out of the qoute! macro so that it is checked within avian_derive rather then the consuming project.

---

Changelog

Adds 2 feature flags to avian_derive which should be setup correctly for both avian2d and avian3d.

Migration Guide

N/A

[Jondolf]

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 crates/avian2d/examples/collision_layers.rs with this PR though, even after running cargo clean, restarting RA, etc. 🤔

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

[ironpeak]

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]

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.