Use official CMake Config for zstd dependency#19117
Closed
uilianries wants to merge 2 commits into
Closed
Conversation
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Member
|
This method doesn't seem to integrate with non-CMake zstd builds, or In theory this would be nice to reduce maintenance, but that still leaves |
Author
Correct, for instance, Ubuntu does not come with it: https://packages.ubuntu.com/jammy/amd64/libzstd-dev/filelist Only the .pc file come with the apt package.
Correct, it would need to bump the zstd version as well. As it introduces not only a breaking change regarding zstd and zstdConfig.cmake is not always available, I'll be closing this PR, but opening a new one with another idea: Consume zstdConfig.cmake as first, but keep the custom findZstd.cmake as fallback, I believe it will be safer and will have the advantage of using the official Cmake file from zstd. Thank you for your time reviewing this PR. |
3 tasks
vszakats
added a commit
to vszakats/curl
that referenced
this pull request
Mar 4, 2026
- [ ] how to control priority? (honor CMAKE's PREFER_CONFIG option?) - [ ] switch default to OFF, initially. - [ ] make a list of deps that support this (and since which versions) - [ ] add for the rest - [ ] test locally? - [ ] test in CI? This may also be a way to add support to curl Find modules for using cmake Configs (in addition to existing `pkg-config` and raw/manual detection). Which in turn may help with static builds. When using MODULE, it's guaranteed to hit curl's Find module first without using Configs, then the Find module may possibly use a `find_package()` limited to Configs, effectively "chaining" them. Then the curl logic needs to create aliases to map the found targets to the `CURL::` namespaced ones, and possibly do other things to make those targets compatible with the rest of the build. I have made minimal tests, so it's mostly theory at this point. curl#20784 (comment) Refs: curl#20013 curl#19117 curl#19156
8 tasks
vszakats
added a commit
to vszakats/curl
that referenced
this pull request
Mar 4, 2026
- [ ] how to control priority? (honor CMAKE's PREFER_CONFIG option?) - [ ] switch default to OFF, initially. - [ ] make a list of deps that support this (and since which versions) - [ ] add for the rest - [ ] test locally? - [ ] test in CI? This may also be a way to add support to curl Find modules for using cmake Configs (in addition to existing `pkg-config` and raw/manual detection). Which in turn may help with static builds. When using MODULE, it's guaranteed to hit curl's Find module first without using Configs, then the Find module may possibly use a `find_package()` limited to Configs, effectively "chaining" them. Then the curl logic needs to create aliases to map the found targets to the `CURL::` namespaced ones, and possibly do other things to make those targets compatible with the rest of the build. I have made minimal tests, so it's mostly theory at this point. curl#20784 (comment) Refs: curl#20013 curl#19117 curl#19156
vszakats
added a commit
to vszakats/curl
that referenced
this pull request
Mar 5, 2026
- [ ] how to control priority? (honor CMAKE's PREFER_CONFIG option?) - [ ] switch default to OFF, initially. - [ ] make a list of deps that support this (and since which versions) - [ ] add for the rest - [ ] test locally? - [ ] test in CI? This may also be a way to add support to curl Find modules for using cmake Configs (in addition to existing `pkg-config` and raw/manual detection). Which in turn may help with static builds. When using MODULE, it's guaranteed to hit curl's Find module first without using Configs, then the Find module may possibly use a `find_package()` limited to Configs, effectively "chaining" them. Then the curl logic needs to create aliases to map the found targets to the `CURL::` namespaced ones, and possibly do other things to make those targets compatible with the rest of the build. I have made minimal tests, so it's mostly theory at this point. curl#20784 (comment) Refs: curl#20013 curl#19117 curl#19156
vszakats
added a commit
to vszakats/curl
that referenced
this pull request
Mar 5, 2026
- [ ] how to control priority? (honor CMAKE's PREFER_CONFIG option?) - [ ] switch default to OFF, initially. - [ ] make a list of deps that support this (and since which versions) - [ ] add for the rest - [ ] test locally? - [ ] test in CI? This may also be a way to add support to curl Find modules for using cmake Configs (in addition to existing `pkg-config` and raw/manual detection). Which in turn may help with static builds. When using MODULE, it's guaranteed to hit curl's Find module first without using Configs, then the Find module may possibly use a `find_package()` limited to Configs, effectively "chaining" them. Then the curl logic needs to create aliases to map the found targets to the `CURL::` namespaced ones, and possibly do other things to make those targets compatible with the rest of the build. I have made minimal tests, so it's mostly theory at this point. curl#20784 (comment) Refs: curl#20013 curl#19117 curl#19156
vszakats
added a commit
to vszakats/curl
that referenced
this pull request
Mar 6, 2026
- [ ] how to control priority? (honor CMAKE's PREFER_CONFIG option?) - [ ] switch default to OFF, initially. - [ ] make a list of deps that support this (and since which versions) - [ ] add for the rest - [ ] test locally? - [ ] test in CI? This may also be a way to add support to curl Find modules for using cmake Configs (in addition to existing `pkg-config` and raw/manual detection). Which in turn may help with static builds. When using MODULE, it's guaranteed to hit curl's Find module first without using Configs, then the Find module may possibly use a `find_package()` limited to Configs, effectively "chaining" them. Then the curl logic needs to create aliases to map the found targets to the `CURL::` namespaced ones, and possibly do other things to make those targets compatible with the rest of the build. I have made minimal tests, so it's mostly theory at this point. curl#20784 (comment) Refs: curl#20013 curl#19117 curl#19156
vszakats
added a commit
to vszakats/curl
that referenced
this pull request
Mar 9, 2026
- [ ] how to control priority? (honor CMAKE's PREFER_CONFIG option?) - [ ] switch default to OFF, initially. - [ ] make a list of deps that support this (and since which versions) - [ ] add for the rest - [ ] test locally? - [ ] test in CI? This may also be a way to add support to curl Find modules for using cmake Configs (in addition to existing `pkg-config` and raw/manual detection). Which in turn may help with static builds. When using MODULE, it's guaranteed to hit curl's Find module first without using Configs, then the Find module may possibly use a `find_package()` limited to Configs, effectively "chaining" them. Then the curl logic needs to create aliases to map the found targets to the `CURL::` namespaced ones, and possibly do other things to make those targets compatible with the rest of the build. I have made minimal tests, so it's mostly theory at this point. curl#20784 (comment) Refs: curl#20013 curl#19117 curl#19156
vszakats
added a commit
to vszakats/curl
that referenced
this pull request
Mar 16, 2026
- [ ] how to control priority? (honor CMAKE's PREFER_CONFIG option?) - [ ] switch default to OFF, initially. - [ ] make a list of deps that support this (and since which versions) - [ ] add for the rest - [ ] test locally? - [ ] test in CI? This may also be a way to add support to curl Find modules for using cmake Configs (in addition to existing `pkg-config` and raw/manual detection). Which in turn may help with static builds. When using MODULE, it's guaranteed to hit curl's Find module first without using Configs, then the Find module may possibly use a `find_package()` limited to Configs, effectively "chaining" them. Then the curl logic needs to create aliases to map the found targets to the `CURL::` namespaced ones, and possibly do other things to make those targets compatible with the rest of the build. I have made minimal tests, so it's mostly theory at this point. curl#20784 (comment) Refs: curl#20013 curl#19117 curl#19156
vszakats
added a commit
to vszakats/curl
that referenced
this pull request
Mar 21, 2026
- [ ] how to control priority? (honor CMAKE's PREFER_CONFIG option?) - [ ] switch default to OFF, initially. - [ ] make a list of deps that support this (and since which versions) - [ ] add for the rest - [ ] test locally? - [ ] test in CI? This may also be a way to add support to curl Find modules for using cmake Configs (in addition to existing `pkg-config` and raw/manual detection). Which in turn may help with static builds. When using MODULE, it's guaranteed to hit curl's Find module first without using Configs, then the Find module may possibly use a `find_package()` limited to Configs, effectively "chaining" them. Then the curl logic needs to create aliases to map the found targets to the `CURL::` namespaced ones, and possibly do other things to make those targets compatible with the rest of the build. I have made minimal tests, so it's mostly theory at this point. curl#20784 (comment) Refs: curl#20013 curl#19117 curl#19156
vszakats
added a commit
that referenced
this pull request
Mar 21, 2026
After limiting `find_package()`/`find_dependency()` calls to curl local Find modules via the `MODULES` keyword, it became possible to detect dependencies via CMake Configs from within those local Find modules, by calling `find_package()` again with the `CONFIG` keyword. This patch implements this. Then maps detection results to the result variables and curl-specific imported targets the rest of the build expects. Also honor recently introduced `*_USE_STATIC_LIBS` (experimental) flags to map to the static target when requested. This adds CMake Configs as an alternative to the existing `pkg-config` and `find_path()`/`find_library()` auto-detection methods. Enabled by default for MSVC, outside vcpkg and when not cross-building. To enable for other cases, or override the default, you can use `-DCURL_USE_CMAKECONFIG=ON` or `OFF`. When enabled, Config detection happens after `pkg-config` and before `find_path()`/`find_library()`. Using CMake's built-in options, you may also manually point to the absolute directory holding Config files: `Libssh2_DIR`, `MbedTLS_DIR`, `NGHTTP2_DIR`, `NGHTTP3_DIR`, `NGTCP2_DIR` v1.19.0+ (with non-fork OpenSSL only), `Zstd_DIR` v1.4.5+ E.g. `-DMbedTLS_DIR=/path/to/mbedtls/lib/cmake/MbedTLS` These dependencies typically need to be built with CMake to support this. Tagged as experimental. Refs: #20013 #19156 #19117 #20784 (comment) Depends-on: fad1eba #20840 Follow-up to 91e06fd #20784 Follow-up to 26c39d8 #20015 Closes #20814
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Greetings!
When consuming libcurl and trying to build it from source, the project uses several custom CMake modules to find dependencies, including zstd.
Most of those dependencies provide an official CMake Config file, which is much safer to use instead of CMake module files due CMake target present there.
In fact, the zstd project provides zstdConfig.cmake, which contains the CMake target zstd::libzstd_static and zstd::libzstd_shared, aggregating all important values, like libraries, compiler flags, include directories, ...
The same applies to its pkg-config file, which is libzstd.pc.
This PR replaces the non-official CMake find module for zstd, and updates the CMakeLists.txt to use the official
zstdConfig.cmakewhen asking to use zstd as a dependency. It's expected to have that CMake config file installed, in case having zstd in the system as well.This change not only makes sure curl will consume what is expected from zstd, but also will reduce the maintenance for this project, as will no longer need to keep an extra CMake find module file in its tree.
Built locally using master branch this current change (2c4e3ab): libcurl-master-zstd-patch.log
Regards.