Skip to content

Add vendored deflate #2037

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

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

kdt3rd
Copy link
Contributor

@kdt3rd kdt3rd commented May 15, 2025

This is still an optionally enabled feature and by default the system one will be used if found as it would previously, but if you force an internal version, or deflate is not found, a vendored (internal) version of deflate will be used.

IF this is acceptable to others, we might consider switching the default and making external versions something that needs to explicitly enabled, and use the internal version by default such that we have api stability in our external libraries, and with the exception of Imath (given maintenance by us), will do the same for any other dependencies such as htj2k

To update (or even to just check if there is an update) the deflate lib when a new release should be vendored in, one can

cd external
../share/util/check_deflate.sh

Copy link
Member

@cary-ilm cary-ilm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finally looking this over. Just so I'm clear, this means no more auto-fetching from https://github.com/ebiggers/libdeflate. Either you get the vendered code or you provide an external pre-built installation (either by having it in a standard place or by specifying -Dlibdeflate_DIR=).

Up until now, when we make a release, we pin the tag to a specific libdeflate release. Now, instead of that, we'll run the check_deflate.sh to pull in that specific release, right?

I think this sounds fine. Same functionality but simpler. The fetching/vendoring is really just a convenience feature for those who prefer ease over control. Anyone who is particular about what version of libdeflate they're using should be specifying it explicitly externally anyway.

@kdt3rd
Copy link
Contributor Author

kdt3rd commented May 23, 2025

precisely - this should also enable a simpler form of the openexr as cmake subproject usage.

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

Successfully merging this pull request may close these issues.

2 participants