Skip to content
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

Enabling multiple features should not cause compilation errors #29

Open
LPGhatguy opened this issue Apr 20, 2023 · 3 comments
Open

Enabling multiple features should not cause compilation errors #29

LPGhatguy opened this issue Apr 20, 2023 · 3 comments

Comments

@LPGhatguy
Copy link

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:

  1. 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.
  2. Inline the math functions into the crate. It looks like Manual refactoring #23 is a step in that direction.
@Ralith
Copy link

Ralith commented Jul 7, 2023

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.

@alteous
Copy link
Member

alteous commented Jul 12, 2023

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.

@Ralith
Copy link

Ralith commented Jul 12, 2023

Yeah, the public API issue is by far the most important.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants