Move static feature out of perf features#13265
Conversation
#5577 fixed a bug on macos due to dynamically linking lzma/xz through static linking. In #7686, this feature was moved to the performance category. This PR moves the `xz2/static` back to the general default features, and, inspired by Homebrew/homebrew-core#222211, it structures and documents the feature flags cleaner
|
I feel like I'm misremembering how this all work. I thought this (and |
|
I don't remember how exactly this came to be, but afaik we always used the allocator. This is fine from my POV, since we generally have builds with cached dependencies. |
|
Why is this a feature at all? |
|
On review, I guess this is correct given the state of the setup! We could probably just remove this feature, alternatively. Otherwise, we might want to add the static features for all the other compression types? |
|
The static feature for lzma/xz is special: Without it, we have a non-manylinux dependency: We keep it as a feature so that redistributors (such as linux distros) can deactivate it. |
zanieb
left a comment
zanieb
left a comment
There was a problem hiding this comment.
<3 thank you for cleaning things up here!
Co-authored-by: Zanie Blue <[email protected]>
|
Sorry, asking for that change on all those comments |
3 participants
#5577 fixed a bug on macos due to dynamically linking lzma/xz through static linking. In #7686, this feature was moved to the performance category.
This PR moves the
xz2/staticback to the general default features, and, inspired by Homebrew/homebrew-core#222211, it structures and documents the feature flags cleaner.We need to take care that this feature does not accidentally disable features we want.