Exporting the component name as passed in is somewhat boring. OTOH it is
convenient for reuse.
- FindNGTCP2: export crypto backend in `NGTCP2_CRYPTO_BACKEND`.
- pass `COMPONENTS` `NGTCP2_CRYPTO_BACKEND` in `curl-config.cmake`.
- FindNGTCP2: fix to skip Config detection when optional `COMPONENTS` is
not passed.
Co-authored-by: Viktor Szakats
Reported-by: x-xiang on github
Fixes#21523
Follow-up to 8fce3e17e6#20814Closes#21540
- use `Threads::Threads` imported target, replacing
`CMAKE_THREAD_LIBS_INIT`. To use the modern form and to allow using
`THREADS_PREFER_PTHREAD_FLAG` option.
- only add Threads library/options if POSIX Threads was detected (not
any other threading backend FindThreads may detect, e.g. the HP one.)
- curl-config.in.cmake: detect and define `Threads::Threads`.
Refs:
https://cmake.org/cmake/help/v3.18/module/FindThreads.htmlhttps://cmake.org/cmake/help/v4.3/module/FindThreads.htmlCloses#21163
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#19117https://github.com/curl/curl/pull/20784#issuecomment-3984318492
Depends-on: fad1ebaecc#20840
Follow-up to 91e06fde1b#20784
Follow-up to 26c39d8df1#20015Closes#20814
- librtmp has no test cases, makes no proper releases and has not had a
single commit within the last year
- librtmp parses the URL itself and requires non-compliant URLs for this
- we have no RTMP tests
- RTMP was used by 2.2% of curl users (self-identified in the 2025
survey)
Closes#20673
Require CMake 3.18 (2020-07-15) or newer, up from 3.7 (2016-11-11)
prior to this patch.
This requirement also applies to the distributed `curl-config.cmake`.
To allow dropping compatibility code maintained for old versions, and to
use features which were unpractical in separate code paths. Also to make
testing, documentation and development easier, CI builds faster due to
CMake performance improvements over time. (e.g. integration tests on
macOS run 8x faster (10 minutes is now under 1.5m) in CI, 2.5x faster on
Windows.)
CMake offers pre-built binaries for major platforms. They work without
an install step, just by unpacking and pointing the cmake command to
them. Making upgrades easy in many cases:
https://cmake.org/download/https://cmake.org/files/https://github.com/Kitware/CMake/releases
CMake 3.18 brings these feature as generally available when building or
consuming curl/libcurl:
LTO support, improved performance, `pkg-config` and interface target
support, `OBJECT` target (for faster libcurl builds), modern invocation
with `-S`/`-B` options, better support for custom linker options,
FetchContent, `GnuTLS::GnuTLS` target, `--verbose` and `--install`
options, `CMAKE_GENERATOR` env, last but not least unity mode and Ninja
generator.
For maximum build speed, use:
`-DCMAKE_UNITY_BUILD=ON -DCURL_DROP_UNUSED=ON`
As for deprecations, C++11 is required to build CMake itself, which may
be a limit on some platforms. autotools continues to cover them.
Follow-up to 9bcdfb3809#20408
Follow-up to a7c974e038#19902
Follow-up to dfbe035c8b#10161
Discussion: https://github.com/curl/curl/discussions/18704Closes#20407
Instead hook up the upstream target name as-is to the local wrapper
target.
To:
- make the hack work regardless of how the upstream target was created.
- make it work the same way in `curl-config.cmake`.
Before this patch it had no guard for `IMPORTED` targets even though
`find_dependencies()` is not guaranteed to create the target expected
if it already existed and was potentially created differently.
Depends-on: #20840
Follow-up to 4f1646ef8a#20486#20419Closes#20839
This CMake global custom option tells it to find dependencies as cmake
Configs first, and only then look for `Find*` modules. This may result
in `find_package()` succeeding, but without actually creating `CURL::*`
imported targets the curl build scripts are expecting.
For dependencies with curl-specific, local, `Find*` modules, we always
want to use them, via the module detection method, and never a
Config-based detection. Ensure this by passing the `MODULE` option to
`find_package()` and `find_dependency()` to make them use `Find*`
modules unconditionally, making them work as expected with the
`CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` option set.
curl uses local Find modules for all dependencies except OpenSSL and
ZLIB. The latter two keep using either CMake's built-in Find modules or
Config method as before this patch.
Also:
- apply the same change to `curl-config.cmake`. To fix consuming curl
with this option set.
Authored-by: Valerie Snyder
Ref: #20764
Follow-up to 16f073ef49#16973
- GHA/distcheck: add a job testing both building and consuming curl with
this option set. (takes 15 seconds)
Use custom NGHTTP2 configuration for an extra twist (not required
to trigger this issue.)
Follow-up to fcde8d7e37#20773
Reported-by: Valerie Snyder
Fixes#20729Closes#20784
Fixing:
```
CMake Error at /path/to/CURL/CURLConfig.cmake:190 (get_target_property):
get_target_property() called with non-existent target "CURL::libssh2".
```
and replacing it with the clearer message:
```
CMake Error at /path/to/CURL/CURLTargets.cmake:61 (set_target_properties):
The link interface of target "CURL::libcurl_static" contains:
CURL::libssh2
but the target was not found. Possible reasons include:
[...]
```
Reported-by: Val S.
Ref: #20729
Follow-up to 16f073ef49#16973Closes#20737
While working #16973, the binutils ld lib order workaround logic
regressed so that it modified the wrong target, writing into the system
`ZLIB::ZLIB` and `OpenSSL::Crypto` ones a `INTERFACE_LINK_LIBRARIES`
property, instead of creating CURL-namespaced targets. Oddly enough,
this also fixed the binutils ld lib ordering issue. It seems this
property makes CMake insert each referenced library in two more
positions (not at the very end though), which allows ld to resolve all
symbols in the cases tested in CI.
Fix by creating the indented namespaced targets, and also creating
these in `curl-config.cmake` to be available when consuming libcurl.
Note that the logic continues doing `get_target_property()` on the two
system targets above. If these targets are defined manually and miss
the `LOCATION` propery, or are defined as aliases, this command may
fail. curl expects these targets be created by CMake's `FindZLIB` and
`FindOpenSSL` built-in Find modules (or ones compatible). Ref: #20419
The binutils ld issue is reproduced by these CI jobs:
- Linux gcc glibc (amd64, arm64)
- Windows gcc zlib-classic (x64)
Currently using this curl-for-win revision:
7d12669daf
Examples:
https://github.com/curl/curl/actions/runs/21332437230/job/61399234023?pr=20427https://github.com/curl/curl/actions/runs/21332437230/job/61399234033?pr=20427
Comparison of lib orders, as passed by CMake to the linker:
without workaround (possibly breaking binutils `ld`):
```diff
-framework [...]
libssl.dylib
libcrypto.dylib
libz.tbd
-lssh2 -lidn2
libldap.tbd
liblber.tbd
-lbrotlidec -lbrotlicommon -lzstd -lnghttp2 -lpsl -lrtmp
-lz
-lssl
-lcrypto
```
before this patch:
```diff
-framework [...]
libssl.dylib
libcrypto.dylib
libz.tbd
+libcrypto.dylib <== inserted via `INTERFACE_LINK_LIBRARIES`
+libz.tbd <== inserted via `INTERFACE_LINK_LIBRARIES`
-lssh2 -lidn2
libldap.tbd
liblber.tbd
+libcrypto.dylib <== inserted via `INTERFACE_LINK_LIBRARIES`
+ibz.tbd <== inserted via `INTERFACE_LINK_LIBRARIES`
-lbrotlidec -lbrotlicommon -lzstd -lnghttp2 -lpsl -lrtmp
-lz
-lssl
-lcrypto
```
after this patch:
```diff
-framework [...]
libssl.dylib
libcrypto.dylib
libz.tbd
-lssh2 -lidn2
libldap.tbd
liblber.tbd
-lbrotlidec -lbrotlicommon -lzstd -lnghttp2 -lpsl -lrtmp
-lz
-lssl
-lcrypto
+libcrypto.dylib <== inserted via `CURL::OpenSSL_Crypto`
+libz.tbd <== inserted via `CURL::ZLIB`
```
Bug: https://github.com/curl/curl/pull/20382#discussion_r2716660108
Reverts: 615c43eae8
Follow-up to 16f073ef49#16973Closes#20427
The CMake config can be consumed by project which enable only language
`CXX`. `CMAKE_C_COMPILER_ID` isn't defined in this case, and the target
definition would be missing. But the check for compiler id isn't really
needed: The target is namespaced and valid, regardless of actual
compiler.
Noticed in https://github.com/microsoft/vcpkg/issues/49518, building cpr.
Follow-up to 16f073ef49#16973Closes#20382
