-
-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Naughty repository structure causes build issues #298
Comments
So, as you're aware, The issue that you're also experiencing is that for e.g. publishing, cargo just packages the crate's own folder, ignoring external folders and files like the entire To be able to publish the crate, I made that shell script to copy the Potential solutionsEventually, I'd like to experiment with a single physics crate that supports both 2D and 3D at the same time by having e.g. separate components for 2D and 3D rigid bodies. This would be more flexible, get rid of the awkward crate structure, allow a single directory for all examples, and also make the dimension feature flags additive, which in general is just good practise and probably preferrable for Bevy. The challenge is avoiding code duplication and excessive trait verbosity, but I'll try to experiment with this when I have time. For now, a potential solution could be to have a separate I think a separate |
Thanks for the detailed explanation. Separate crates sounds like a reasonable idea, I think I'd be down for that. Though it does sound like it'd make the development workflow a bit more annoying (for contributors). On the other hand, I've also tried experimenting with a simpler idea using symlinks instead: https://github.com/musjj/bevy_xpbd/tree/symlink |
unfortunately i also ran into this issue packaging a game that vendored this dependency. Both of your solutions seem good to me and if unifying xpbd into a single crate seems like a better solution for development reasons, having to enable features when adding the crate does not seem like a big problem. But if you dont want that, you could set 2d and 3d as default features of the crate, so disabling one of them would become a way for people wanting to optimize compile time. |
Building
bevy_xpbd
from a git source withcargo vendor
fails with an error involving../../src/lib.rs
.To reproduce:
The error:
The error is probably caused by this:
https://github.com/Jondolf/bevy_xpbd/blob/7e7e14d210efb27177d975367bc47090cfa3652d/crates/bevy_xpbd_2d/Cargo.toml#L34-L37
I'm also getting the same error when running
cargo package -p bevy_xpbd_2d
locally within this repository. So I'm guessing that the package structure is actually just invalid. Do you manually copysrc
into each sub-crate every time you publish to the registry?I think the structure of the repository should definitely be revised so that it is compliant with
cargo
.EDIT:
It looks that there's this thing:
https://github.com/Jondolf/bevy_xpbd/blob/7e7e14d210efb27177d975367bc47090cfa3652d/publish.sh#L11-L14
There's gotta be a better way.
The text was updated successfully, but these errors were encountered: