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
Currently, mikktspace has an nalgebra feature (enabled by default) and a glam feature. This is discouraged as it means two libraries each depending on mikktspace might be incompatible with each other with no way for a user to fix it.
We ran into that incompatibility in our game, where the main game was depending on mikktspace with
mikktspace = { version = "0.3.0", default-features = false, features = ["glam"] }
but a crate that we depended on used
mikktspace = "0.3.0"
...causing a compilation error in mikktspace.
There are two pretty good approaches to solve this issue generally:
Pick a single math library to use internally. This can help with maintainability. Math libraries, especially glam, aren't too heavy on compilation times so this might not be so bad.
Inline the math functions into the crate. It looks like Manual refactoring #23 is a step in that direction.
The text was updated successfully, but these errors were encountered:
Note that nalgebra is pretty heavy, so it probably shouldn't be used internally. It's also important not to have a math library in the public API, since they tend to break frequently and hence pose a major semver compatibility hazard.
It's also important not to have a math library in the public API
I agree. If I've understood correctly, this is really the root cause of the issue. I suggest we use a neutral vector format for input and output instead.
The heavy library dependency is heavy but it's a least dependable. I'm beginning to grow tired of discussing which math libraries should and should not be used at this point.
Currently, mikktspace has an
nalgebra
feature (enabled by default) and aglam
feature. This is discouraged as it means two libraries each depending on mikktspace might be incompatible with each other with no way for a user to fix it.We ran into that incompatibility in our game, where the main game was depending on mikktspace with
but a crate that we depended on used
...causing a compilation error in mikktspace.
There are two pretty good approaches to solve this issue generally:
The text was updated successfully, but these errors were encountered: