mmo-ref/dep-curl
1
0
Fork 0
mirror of https://github.com/curl/curl synced 2026-08-25 12:32:35 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
dep-curl/CMake/curl-config.in.cmake

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

197 lines
6.4 KiB
CMake
Raw Permalink Normal View History

copyright: fix out-of-date copyright ranges and missing headers Reported by the new script 'scripts/copyright.pl'. The script has a regex whitelist for the files that don't need copyright headers. Removed three (mostly usesless) README files from docs/ Closes #5141
2020-03-23 14:44:29 +01:00
#***************************************************************************
# _ _ ____ _
# Project ___| | | | _ \| |
# / __| | | | |_) | |
# | (__| |_| | _ <| |___
# \___|\___/|_| \_\_____|
#
copyright: update all copyright lines and remove year ranges - they are mostly pointless in all major jurisdictions - many big corporations and projects already don't use them - saves us from pointless churn - git keeps history for us - the year range is kept in COPYING checksrc is updated to allow non-year using copyright statements Closes #10205
2023-01-02 13:51:48 +01:00
# Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
copyright: fix out-of-date copyright ranges and missing headers Reported by the new script 'scripts/copyright.pl'. The script has a regex whitelist for the files that don't need copyright headers. Removed three (mostly usesless) README files from docs/ Closes #5141
2020-03-23 14:44:29 +01:00
#
# This software is licensed as described in the file COPYING, which
# you should have received as part of this distribution. The terms
curl.se: new home Closes #6172
2020-11-04 14:02:01 +01:00
# are also available at https://curl.se/docs/copyright.html.
copyright: fix out-of-date copyright ranges and missing headers Reported by the new script 'scripts/copyright.pl'. The script has a regex whitelist for the files that don't need copyright headers. Removed three (mostly usesless) README files from docs/ Closes #5141
2020-03-23 14:44:29 +01:00
#
# You may opt to use, copy, modify, merge, publish, distribute and/or sell
# copies of the Software, and permit persons to whom the Software is
# furnished to do so, under the terms of the COPYING file.
#
# This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
# KIND, either express or implied.
#
# SPDX-License-Identifier: curl
copyright: make repository REUSE compliant Add licensing and copyright information for all files in this repository. This either happens in the file itself as a comment header or in the file `.reuse/dep5`. This commit also adds a Github workflow to check pull requests and adapts copyright.pl to the changes. Closes #8869
2022-05-17 11:16:50 +02:00
#
copyright: fix out-of-date copyright ranges and missing headers Reported by the new script 'scripts/copyright.pl'. The script has a regex whitelist for the files that don't need copyright headers. Removed three (mostly usesless) README files from docs/ Closes #5141
2020-03-23 14:44:29 +01:00
###########################################################################
CMake: Improve config installation Use 'GNUInstallDirs' standard module to set destinations of installed files. Use uppercase "CURL" names instead of lowercase "curl" to match standard 'FindCURL.cmake' CMake module: * https://cmake.org/cmake/help/latest/module/FindCURL.html Meaning: * Install 'CURLConfig.cmake' instead of 'curl-config.cmake' * User should call 'find_package(CURL)' instead of 'find_package(curl)' Use 'configure_package_config_file' function to generate 'CURLConfig.cmake' file. This will make 'curl-config.cmake.in' template file smaller and handle components better. E.g. current configuration report no error if user specified unknown components (note: new configuration expects no components, report error if user will try to specify any). Closes https://github.com/curl/curl/pull/2849
2018-07-18 02:31:51 +03:00
@PACKAGE_INIT@
cmake: Export libcurl and curl targets to use by other cmake projects The config files define curl and libcurl targets as imported targets CURL::curl and CURL::libcurl. For backward compatibility with CMake- provided find-module the CURL_INCLUDE_DIRS and CURL_LIBRARIES are also set. Closes #1879
2017-09-10 16:56:16 +02:00
cmake: add CMake Config-based dependency detection 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 https://github.com/curl/curl/pull/20784#issuecomment-3984318492 Depends-on: fad1ebaecc0c489d38c0a9a155f63fdfd9086907 #20840 Follow-up to 91e06fde1b520bc29c7996749734451e03cd549f #20784 Follow-up to 26c39d8df182a63d28d81ed2b044e6a343519d1a #20015 Closes #20814
2026-03-03 14:48:32 +01:00
option(CURL_USE_CMAKECONFIG "Enable detecting @PROJECT_NAME@ dependencies via CMake Config. Default: @CURL_USE_CMAKECONFIG@"
"@CURL_USE_CMAKECONFIG@")
cmakelint: also lint CMake `.in` files, fix a long line ``` CMakeConfigurableFile.in cmake_uninstall.cmake.in curl-config.cmake.in ``` Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #19773
2025-11-30 23:27:06 +01:00
option(CURL_USE_PKGCONFIG "Enable pkg-config to detect @PROJECT_NAME@ dependencies. Default: @CURL_USE_PKGCONFIG@"
"@CURL_USE_PKGCONFIG@")
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
cmake: verify minimum CMake version in `curl-config.cmake` Show a message if the CMake version is lower than that when consuming libcurl via the CMake config. The minimum CMake version on consumption is for now the same as the minimum required (v3.7) to build curl itself. Ref: https://cmake.org/cmake/help/v3.7/variable/CMAKE_MINIMUM_REQUIRED_VERSION.html Ref: #18704 (discussion) Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #19776
2025-11-30 23:22:59 +01:00
if(CMAKE_VERSION VERSION_LESS @CMAKE_MINIMUM_REQUIRED_VERSION@)
message(STATUS "@PROJECT_NAME@: @PROJECT_NAME@-specific Find modules require "
"CMake @CMAKE_MINIMUM_REQUIRED_VERSION@ or upper, found: ${CMAKE_VERSION}.")
endif()
cmake: uniform ZLIB to use USE_ variable and clean curl-config.cmake.in Closes #3123
2018-10-27 11:23:19 +01:00
include(CMakeFindDependencyMacro)
cmake: save and restore `CMAKE_MODULE_PATH` in `curl-config.cmake` Reported-by: Kai Pastor Bug: https://github.com/curl/curl/pull/16973#discussion_r2572957270 Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #19758
2025-11-29 14:17:04 +01:00
cmake: enable pthreads for BoringSSL/AWS-LC Depends on 6828df7d2116fe680a0d012b06a4501e26efa99b #21176 Closes #21168
2026-03-28 23:23:31 +01:00
if("@HAVE_THREADS_POSIX@" OR "@HAVE_THREADS_POSIX_BORINGSSL@")
cmake: use `Threads::Threads` imported target for POSIX Threads - 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.html https://cmake.org/cmake/help/v4.3/module/FindThreads.html Closes #21163
2026-03-28 23:23:01 +01:00
find_dependency(Threads) # for Threads::Threads
endif()
cmake: tidy up - unroll two short loops. - unfold lines. - merge lines with their comments. - add missing quotes. - tidy up grammar in error/warning messages. Cherry-picked from #14692 Closes #14998
2024-08-26 11:38:17 +02:00
if("@USE_OPENSSL@")
cmake: test integration with old cmake (v3.11.4 2018-03-28) Tests with old cmake are slow. (no Ninja, no unity, and running slower than recent versions.) It also revealed that 3.7.2 2017-01-13 is too old to consume curl via `find_package()` due to: ``` CMake Error at bld-curl/_pkg/lib/cmake/CURL/CURLConfig.cmake:69 (add_library): add_library cannot create ALIAS target "CURL::libcurl" because target "CURL::libcurl_shared" is IMPORTED. Call Stack (most recent call first): CMakeLists.txt:48 (find_package) CMake Error at bld-curl/_pkg/lib/cmake/CURL/CURLConfig.cmake:69 (add_library): add_library cannot create ALIAS target "CURL::libcurl" because target "CURL::libcurl_shared" is IMPORTED. Call Stack (most recent call first): CMakeLists.txt:49 (find_package) ``` The mitigation for this issue requires 3.11. Also: - rename a few existing envs to use the `TEST_` prefix. - make the `find_package` test provider stage verbose. - fix issue when consuming with cmake 3.7.2 (all platforms): ``` CMake Error at /home/runner/cmake-3.7.2-Linux-x86_64/share/cmake-3.7/Modules/CMakeFindDependencyMacro.cmake:25 (message): Invalid arguments to find_dependency. VERSION is empty Call Stack (most recent call first): bld-curl/_pkg/lib/cmake/CURL/CURLConfig.cmake:52 (find_dependency) CMakeLists.txt:48 (find_package) ``` Ref: https://github.com/curl/curl/actions/runs/14906066962/job/41868621979?pr=17293#step:9:1199 Closes #17293
2025-05-08 13:09:29 +02:00
if("@OPENSSL_VERSION_MAJOR@")
find_dependency(OpenSSL "@OPENSSL_VERSION_MAJOR@")
else()
find_dependency(OpenSSL)
endif()
cmake: enable binutils ld workaround for all toolchains at build-time To make it available for GCC if used when consuming libcurl. Also add comment to `curl-config.cmake` explaining why these odd targets are defined there. Bug: https://github.com/curl/curl/pull/20382#discussion_r2716660108 Follow-up to 3e841630ece59c04e26058a761302f38370fd0cc #20427 Follow-up to ef3101d1819928a7799309a16cc531818778e5c7 #20382 Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #20434
2026-01-25 20:54:55 +01:00
# Define lib duplicate to fixup lib order for GCC binutils ld in static builds
cmake: fix logic for openssl/zlib binutils ld workaround 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: https://github.com/curl/curl-for-win/commit/7d12669dafc5aadb525415abde2152a44e10f07d Examples: https://github.com/curl/curl/actions/runs/21332437230/job/61399234023?pr=20427 https://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: https://github.com/curl/curl/commit/615c43eae8f926418c8205b6fe4ff693e8fc6b7d Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #20427
2026-01-25 13:04:58 +01:00
if(TARGET OpenSSL::Crypto AND NOT TARGET CURL::OpenSSL_Crypto)
add_library(CURL::OpenSSL_Crypto INTERFACE IMPORTED)
cmake: rework binutils ld hack to not read `LOCATION` property 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 4f1646ef8a9ae3052ee3e13a09c418de9ec85819 #20486 #20419 Closes #20839
2026-03-06 15:43:59 +01:00
set_target_properties(CURL::OpenSSL_Crypto PROPERTIES INTERFACE_LINK_LIBRARIES OpenSSL::Crypto)
cmake: fix logic for openssl/zlib binutils ld workaround 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: https://github.com/curl/curl-for-win/commit/7d12669dafc5aadb525415abde2152a44e10f07d Examples: https://github.com/curl/curl/actions/runs/21332437230/job/61399234023?pr=20427 https://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: https://github.com/curl/curl/commit/615c43eae8f926418c8205b6fe4ff693e8fc6b7d Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #20427
2026-01-25 13:04:58 +01:00
endif()
cmake: uniform ZLIB to use USE_ variable and clean curl-config.cmake.in Closes #3123
2018-10-27 11:23:19 +01:00
endif()
cmake: tidy up - unroll two short loops. - unfold lines. - merge lines with their comments. - add missing quotes. - tidy up grammar in error/warning messages. Cherry-picked from #14692 Closes #14998
2024-08-26 11:38:17 +02:00
if("@HAVE_LIBZ@")
find_dependency(ZLIB "@ZLIB_VERSION_MAJOR@")
cmake: enable binutils ld workaround for all toolchains at build-time To make it available for GCC if used when consuming libcurl. Also add comment to `curl-config.cmake` explaining why these odd targets are defined there. Bug: https://github.com/curl/curl/pull/20382#discussion_r2716660108 Follow-up to 3e841630ece59c04e26058a761302f38370fd0cc #20427 Follow-up to ef3101d1819928a7799309a16cc531818778e5c7 #20382 Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #20434
2026-01-25 20:54:55 +01:00
# Define lib duplicate to fixup lib order for GCC binutils ld in static builds
cmake: fix logic for openssl/zlib binutils ld workaround 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: https://github.com/curl/curl-for-win/commit/7d12669dafc5aadb525415abde2152a44e10f07d Examples: https://github.com/curl/curl/actions/runs/21332437230/job/61399234023?pr=20427 https://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: https://github.com/curl/curl/commit/615c43eae8f926418c8205b6fe4ff693e8fc6b7d Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #20427
2026-01-25 13:04:58 +01:00
if(TARGET ZLIB::ZLIB AND NOT TARGET CURL::ZLIB)
add_library(CURL::ZLIB INTERFACE IMPORTED)
cmake: rework binutils ld hack to not read `LOCATION` property 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 4f1646ef8a9ae3052ee3e13a09c418de9ec85819 #20486 #20419 Closes #20839
2026-03-06 15:43:59 +01:00
set_target_properties(CURL::ZLIB PROPERTIES INTERFACE_LINK_LIBRARIES ZLIB::ZLIB)
cmake: fix logic for openssl/zlib binutils ld workaround 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: https://github.com/curl/curl-for-win/commit/7d12669dafc5aadb525415abde2152a44e10f07d Examples: https://github.com/curl/curl/actions/runs/21332437230/job/61399234023?pr=20427 https://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: https://github.com/curl/curl/commit/615c43eae8f926418c8205b6fe4ff693e8fc6b7d Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #20427
2026-01-25 13:04:58 +01:00
endif()
cmake: link curl to the OpenSSL targets instead of lib absolute paths Reviewed-by: Jakub Zakrzewski Reviewed-by: Sergei Nikulov Closes #2753
2018-07-17 01:13:18 -07:00
endif()
cmake: narrow scope of custom `CMAKE_MODULE_PATH` in `curl-config.cmake` Set it only while using local Find modules, leave it as-is while using system ones. Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Cherry-picked from #19776
2025-12-01 01:17:41 +01:00
set(_curl_cmake_module_path_save ${CMAKE_MODULE_PATH})
cmake: drop support for CMake 3.17 and older 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 9bcdfb3809a41327054421368bdea77ea17e6f90 #20408 Follow-up to a7c974e038572bd1d4a653afbd6de5fad5a10215 #19902 Follow-up to dfbe035c8b39b056a234bc76df3f384f7a7a24af #10161 Discussion: https://github.com/curl/curl/discussions/18704 Closes #20407
2025-11-26 19:07:19 +01:00
list(PREPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR})
cmake: narrow scope of custom `CMAKE_MODULE_PATH` in `curl-config.cmake` Set it only while using local Find modules, leave it as-is while using system ones. Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Cherry-picked from #19776
2025-12-01 01:17:41 +01:00
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
set(_curl_libs "")
cmake: narrow scope of custom `CMAKE_MODULE_PATH` in `curl-config.cmake` Set it only while using local Find modules, leave it as-is while using system ones. Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Cherry-picked from #19776
2025-12-01 01:17:41 +01:00
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
if("@HAVE_BROTLI@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Brotli MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::brotli)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_ARES@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Cares MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::cares)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@HAVE_GSSAPI@")
gssapi: add support for Apple GSS Framework Add support for the native GSS Framework on Apple targets, which is Apple's fork of Heimdal. This option allows to drop Apple's deprecated MIT Kerberos compatibility shim "mit-krb5/1.7-prerelease". Source code uses different headers, other than that no source changes are necessary. You can enable by configuring with: autotools: `--enable-gssapi-apple` CMake: `-DCURL_USE_GSSAPI=ON -DCURL_GSS_FLAVOR=Apple` These options are experimental, and may receive breaking updates till the GSS backend selection logic settles, for Apple and also for the GNU and MIT implementation. Version string: ``` curl 8.21.0-DEV (aarch64-apple-darwin25.4.0) libcurl/8.21.0-DEV OpenSSL/3.6.2 zlib/1.2.12 AppleIDN AppleGSS OpenLDAP/2.4.28/Apple ``` Also: - drop in-source deprecation warning suppressions when using AppleGSS. - GHA/macos: enable Apple GSS in CI jobs. Supported by: iOS 5.0+, iPadOS 5.0+, Mac Catalyst 13.0+, macOS 10.14+, visionOS 1.0+ Ref: https://developer.apple.com/documentation/gss Ref: #19109 Closes #22052
2025-10-25 01:40:44 +02:00
find_dependency(GSS MODULE COMPONENTS "@GSS_FLAVOR@")
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::gss)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_BACKTRACE@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Libbacktrace MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::libbacktrace)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_GSASL@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Libgsasl MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::libgsasl)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if(NOT "@USE_WIN32_LDAP@" AND NOT "@CURL_DISABLE_LDAP@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(LDAP MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::ldap)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@HAVE_LIBIDN2@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Libidn2 MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::libidn2)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_LIBPSL@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Libpsl MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::libpsl)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_LIBSSH@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Libssh MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::libssh)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_LIBSSH2@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Libssh2 MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::libssh2)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_LIBUV@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Libuv MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::libuv)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_MBEDTLS@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(MbedTLS MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::mbedtls)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_NGHTTP2@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(NGHTTP2 MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::nghttp2)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_NGHTTP3@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(NGHTTP3 MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::nghttp3)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_NGTCP2@")
cmake: quote `COMPONENTS` string in `curl-config.in.cmake` For consistency and for handling an accidental empty more gracefully. Follow-up to 7d546e52b21c94e1d4f6669d2d4d64f79bff0d7b #21540 Closes #21699
2026-05-20 18:43:41 +02:00
find_dependency(NGTCP2 MODULE COMPONENTS "@NGTCP2_CRYPTO_BACKEND@")
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::ngtcp2)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_GNUTLS@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(GnuTLS MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::gnutls)
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Nettle MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::nettle)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_QUICHE@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Quiche MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::quiche)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_RUSTLS@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Rustls MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::rustls)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@USE_WOLFSSL@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(WolfSSL MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::wolfssl)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
if("@HAVE_ZSTD@")
cmake: fix building with `CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #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 fcde8d7e3745df3b4d83c86d0a1f0caef398511b #20773 Reported-by: Valerie Snyder Fixes #20729 Closes #20784
2026-03-01 16:19:33 +01:00
find_dependency(Zstd MODULE)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
list(APPEND _curl_libs CURL::zstd)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
cmake: save and restore `CMAKE_MODULE_PATH` in `curl-config.cmake` Reported-by: Kai Pastor Bug: https://github.com/curl/curl/pull/16973#discussion_r2572957270 Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #19758
2025-11-29 14:17:04 +01:00
set(CMAKE_MODULE_PATH ${_curl_cmake_module_path_save})
cmake: enable binutils ld workaround for all toolchains at build-time To make it available for GCC if used when consuming libcurl. Also add comment to `curl-config.cmake` explaining why these odd targets are defined there. Bug: https://github.com/curl/curl/pull/20382#discussion_r2716660108 Follow-up to 3e841630ece59c04e26058a761302f38370fd0cc #20427 Follow-up to ef3101d1819928a7799309a16cc531818778e5c7 #20382 Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #20434
2026-01-25 20:54:55 +01:00
# Define lib duplicate to fixup lib order for GCC binutils ld in static builds
cmake: always define `CURL::win32_winsock` on Windows in `curl-config.cmake` 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 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Closes #20382
2026-01-21 09:04:14 +01:00
if(WIN32 AND NOT TARGET CURL::win32_winsock)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
add_library(CURL::win32_winsock INTERFACE IMPORTED)
cmake: fix `ws2_32` reference in `curl-config.cmake` Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973 Follow-up to 554dfa556886c3d7425f6690f3fc408128bf4744 #17927 Closes #19775
2025-12-01 00:34:33 +01:00
set_target_properties(CURL::win32_winsock PROPERTIES INTERFACE_LINK_LIBRARIES "ws2_32")
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
endif()
cmake: add find_dependency call for ZLIB to CMake config file
2018-10-11 19:55:53 +01:00
CMake: Improve config installation Use 'GNUInstallDirs' standard module to set destinations of installed files. Use uppercase "CURL" names instead of lowercase "curl" to match standard 'FindCURL.cmake' CMake module: * https://cmake.org/cmake/help/latest/module/FindCURL.html Meaning: * Install 'CURLConfig.cmake' instead of 'curl-config.cmake' * User should call 'find_package(CURL)' instead of 'find_package(curl)' Use 'configure_package_config_file' function to generate 'CURLConfig.cmake' file. This will make 'curl-config.cmake.in' template file smaller and handle components better. E.g. current configuration report no error if user specified unknown components (note: new configuration expects no components, report error if user will try to specify any). Closes https://github.com/curl/curl/pull/2849
2018-07-18 02:31:51 +03:00
include("${CMAKE_CURRENT_LIST_DIR}/@TARGETS_EXPORT_NAME@.cmake")
cmake: support building static and shared libcurl in one go This patch adds the ability to build a static and shared libcurl library in a single build session. It also adds an option to select which one to use when building the curl executable. New build options: - `BUILD_STATIC_LIBS`. Default: `OFF`. Enabled automatically if `BUILD_SHARED_LIBS` is `OFF`. - `BUILD_STATIC_CURL`. Default: `OFF`. Requires `BUILD_STATIC_LIBS` enabled. Enabled automatically if building static libcurl only. - `STATIC_LIB_SUFFIX`. Default: empty. - `IMPORT_LIB_SUFFIX`. Default: `_imp` if implib filename would collide with static lib name (typically with MSVC) in Windows builds. Otherwise empty. Also: - Stop setting the `CURL_STATICLIB` macro via `curl_config.h`, and pass it directly to the compiler. This also allows to delete a condition from `tests/server/CMakeLists.txt`. - Complete a TODO by following the logic used in autotools (also for `LIBCURL_NO_SHARED`), and set `-DCURL_STATICLIB` in `Cflags:` of `libcurl.pc` for _static-only_ curl builds. - Convert an existing CI test to build both shared and static libcurl. Closes #11505
2023-06-22 09:24:37 +00:00
# Alias for either shared or static library
cmake: use `LIB_NAME` in `curl-config.cmake.in` Cherry-picked from #16973 Closes #17195
2025-04-26 09:17:32 +02:00
if(NOT TARGET @PROJECT_NAME@::@LIB_NAME@)
add_library(@PROJECT_NAME@::@LIB_NAME@ ALIAS @PROJECT_NAME@::@LIB_SELECTED@)
cmake: fix multiple include of CURL package Fixes errors on second `find_package(CURL)`. This is a frequent case with transitive dependencies: ``` CMake Error at ...: add_library cannot create ALIAS target "CURL::libcurl" because another target with the same name already exists. ``` Test to reproduce: ```cmake cmake_minimum_required(VERSION 3.27) # must be 3.18 or higher project(curl) set(CURL_DIR "example/lib/cmake/CURL/") find_package(CURL CONFIG REQUIRED) find_package(CURL CONFIG REQUIRED) # fails add_executable(main main.c) target_link_libraries(main CURL::libcurl) ``` Ref: https://cmake.org/cmake/help/latest/release/3.18.html#other-changes Ref: https://cmake.org/cmake/help/v3.18/policy/CMP0107.html Ref: #12300 Assisted-by: Harry Mallon Closes #11913
2023-09-22 07:48:36 +02:00
endif()
cmake: bring `curl-config.cmake` closer to `FindCURL` Set `CURL_LIBRARIES` and `CURL_INCLUDE_DIRS` variables for compatibility with CMake's `FindCURL.cmake`: https://github.com/Kitware/CMake/blob/b411d0146c2e06acfb0c823bb039e99f0191b611/Modules/FindCURL.cmake#L209 For dependent projects, CMake's suggestion is to replace `CURL_LIBRARIES` with `CURL::libcurl`, and drop `CURL_INCLUDE_DIRS`. Reported-by: Aurélien Pierre Ref: https://curl.se/mail/lib-2024-06/0014.html Ref: https://gitlab.kitware.com/cmake/cmake/-/issues/24580 Closes #13897
2024-06-05 22:35:48 +02:00
# For compatibility with CMake's FindCURL.cmake
cmake: publish/check supported protocols/features via `CURLConfig.cmake` Via these variables, as lists: - `CURL_SUPPORTED_PROTOCOLS` - `CURL_SUPPORTED_FEATURES` As individual flags: - `CURL_SUPPORTS_<protocol/feature>` = `TRUE` Also: - set `CURL_VERSION_STRING` which was missing when using `find_package(CURL CONFIG)` or `find_package(CURL NO_MODULE)`. - set `CURL_<prototol/feature>_FOUND` for compatibility. - show full list of missing but required `COMPONENTS`. Assisted-by: Derek Huang Fixes #15854 Closes #15858
2024-12-29 22:34:09 +01:00
set(CURL_VERSION_STRING "@CURLVERSION@")
cmake: use `LIB_NAME` in `curl-config.cmake.in` Cherry-picked from #16973 Closes #17195
2025-04-26 09:17:32 +02:00
set(CURL_LIBRARIES @PROJECT_NAME@::@LIB_NAME@)
cmake: define dependencies as `IMPORTED` interface targets Rework the way curl's custom Find modules advertise their properties. Before this patch, Find modules returned detected dependency properties (header dirs, libs, libdirs, C flags, etc.) via global variables. curl's main `CMakeLists.txt` copied their values into global lists, which it later applied to targets. This solution worked internally, but it was unsuited for the public, distributed `CURLConfig.cmake` and publishing curl's Find modules with it, due to polluting the namespace of consumer projects. It's also impractical to apply the many individual variables to every targets depending on libcurl. To allow using Find modules in consumer projects, this patch makes them define as imported interface targets, named `CURL::<dependency>`. Then store dependency information as target properties. It avoids namespace pollution and makes the dependency information apply automatically to all targets using `CURL::libcurl_static`. Find modules continue to return `*_FOUND` and `*_VERSION` variables. For dependencies detected via `pkg-config`, CMake 3.16+ is recommended. Older CMake versions have a varying degree of support for propagating/handling library directories. This may cause issues in envs where dependencies reside in non-system locations and detected via `pkg-config` (e.g. macOS + Homebrew). Use `CURL_USE_PKGCONFIG=OFF` to fix these issues. Or upgrade to newer CMake, or link libcurl dynamically. Also: - re-enable `pkg-config` for old cmake `find_library()` integration tests. - make `curlinfo` build after these changes. - distribute local Find modules. - export the raw list of lib dependencies via `CURL_LIBRARIES_PRIVATE`. - `CURLconfig.cmake`: use curl's Find modules to detect dependencies in the consumer env. - add custom property to target property debug function. - the curl build process no longer modifies `CMAKE_C_FLAGS`. Follow-up to e86542038dda88dadf8959584e803895f979310c #17047 Ref: #14930 Ref: https://github.com/libssh2/libssh2/pull/1535 Ref: https://github.com/libssh2/libssh2/pull/1571 Ref: https://github.com/libssh2/libssh2/pull/1581 Ref: https://github.com/libssh2/libssh2/pull/1623 Closes #16973
2025-03-27 01:15:16 +01:00
set(CURL_LIBRARIES_PRIVATE "@LIBCURL_PC_LIBS_PRIVATE_LIST@")
cmake: bring `curl-config.cmake` closer to `FindCURL` Set `CURL_LIBRARIES` and `CURL_INCLUDE_DIRS` variables for compatibility with CMake's `FindCURL.cmake`: https://github.com/Kitware/CMake/blob/b411d0146c2e06acfb0c823bb039e99f0191b611/Modules/FindCURL.cmake#L209 For dependent projects, CMake's suggestion is to replace `CURL_LIBRARIES` with `CURL::libcurl`, and drop `CURL_INCLUDE_DIRS`. Reported-by: Aurélien Pierre Ref: https://curl.se/mail/lib-2024-06/0014.html Ref: https://gitlab.kitware.com/cmake/cmake/-/issues/24580 Closes #13897
2024-06-05 22:35:48 +02:00
set_and_check(CURL_INCLUDE_DIRS "@PACKAGE_CMAKE_INSTALL_INCLUDEDIR@")
cmake: publish/check supported protocols/features via `CURLConfig.cmake` Via these variables, as lists: - `CURL_SUPPORTED_PROTOCOLS` - `CURL_SUPPORTED_FEATURES` As individual flags: - `CURL_SUPPORTS_<protocol/feature>` = `TRUE` Also: - set `CURL_VERSION_STRING` which was missing when using `find_package(CURL CONFIG)` or `find_package(CURL NO_MODULE)`. - set `CURL_<prototol/feature>_FOUND` for compatibility. - show full list of missing but required `COMPONENTS`. Assisted-by: Derek Huang Fixes #15854 Closes #15858
2024-12-29 22:34:09 +01:00
set(CURL_SUPPORTED_PROTOCOLS "@CURL_SUPPORTED_PROTOCOLS_LIST@")
set(CURL_SUPPORTED_FEATURES "@CURL_SUPPORTED_FEATURES_LIST@")
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
foreach(_curl_item IN LISTS CURL_SUPPORTED_PROTOCOLS CURL_SUPPORTED_FEATURES)
set(CURL_SUPPORTS_${_curl_item} TRUE)
cmake: publish/check supported protocols/features via `CURLConfig.cmake` Via these variables, as lists: - `CURL_SUPPORTED_PROTOCOLS` - `CURL_SUPPORTED_FEATURES` As individual flags: - `CURL_SUPPORTS_<protocol/feature>` = `TRUE` Also: - set `CURL_VERSION_STRING` which was missing when using `find_package(CURL CONFIG)` or `find_package(CURL NO_MODULE)`. - set `CURL_<prototol/feature>_FOUND` for compatibility. - show full list of missing but required `COMPONENTS`. Assisted-by: Derek Huang Fixes #15854 Closes #15858
2024-12-29 22:34:09 +01:00
endforeach()
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
set(_curl_missing_req "")
foreach(_curl_item IN LISTS CURL_FIND_COMPONENTS)
if(CURL_SUPPORTS_${_curl_item})
set(CURL_${_curl_item}_FOUND TRUE)
elseif(CURL_FIND_REQUIRED_${_curl_item})
list(APPEND _curl_missing_req ${_curl_item})
cmake: publish/check supported protocols/features via `CURLConfig.cmake` Via these variables, as lists: - `CURL_SUPPORTED_PROTOCOLS` - `CURL_SUPPORTED_FEATURES` As individual flags: - `CURL_SUPPORTS_<protocol/feature>` = `TRUE` Also: - set `CURL_VERSION_STRING` which was missing when using `find_package(CURL CONFIG)` or `find_package(CURL NO_MODULE)`. - set `CURL_<prototol/feature>_FOUND` for compatibility. - show full list of missing but required `COMPONENTS`. Assisted-by: Derek Huang Fixes #15854 Closes #15858
2024-12-29 22:34:09 +01:00
endif()
endforeach()
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
if(_curl_missing_req)
string(REPLACE ";" " " _curl_missing_req "${_curl_missing_req}")
cmake: publish/check supported protocols/features via `CURLConfig.cmake` Via these variables, as lists: - `CURL_SUPPORTED_PROTOCOLS` - `CURL_SUPPORTED_FEATURES` As individual flags: - `CURL_SUPPORTS_<protocol/feature>` = `TRUE` Also: - set `CURL_VERSION_STRING` which was missing when using `find_package(CURL CONFIG)` or `find_package(CURL NO_MODULE)`. - set `CURL_<prototol/feature>_FOUND` for compatibility. - show full list of missing but required `COMPONENTS`. Assisted-by: Derek Huang Fixes #15854 Closes #15858
2024-12-29 22:34:09 +01:00
if(CURL_FIND_REQUIRED)
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
message(FATAL_ERROR "@PROJECT_NAME@: missing required components: ${_curl_missing_req}")
cmake: publish/check supported protocols/features via `CURLConfig.cmake` Via these variables, as lists: - `CURL_SUPPORTED_PROTOCOLS` - `CURL_SUPPORTED_FEATURES` As individual flags: - `CURL_SUPPORTS_<protocol/feature>` = `TRUE` Also: - set `CURL_VERSION_STRING` which was missing when using `find_package(CURL CONFIG)` or `find_package(CURL NO_MODULE)`. - set `CURL_<prototol/feature>_FOUND` for compatibility. - show full list of missing but required `COMPONENTS`. Assisted-by: Derek Huang Fixes #15854 Closes #15858
2024-12-29 22:34:09 +01:00
endif()
cmake: namespace all local variables in `curl-config.cmake` Also: - apply it to the local copy of this code in `lib/CMakeLists.txt`. - replace 'CURL' with `@PROJECT_NAME@` in a message. Closes #19777
2025-12-01 01:53:25 +01:00
unset(_curl_missing_req)
cmake: publish/check supported protocols/features via `CURLConfig.cmake` Via these variables, as lists: - `CURL_SUPPORTED_PROTOCOLS` - `CURL_SUPPORTED_FEATURES` As individual flags: - `CURL_SUPPORTS_<protocol/feature>` = `TRUE` Also: - set `CURL_VERSION_STRING` which was missing when using `find_package(CURL CONFIG)` or `find_package(CURL NO_MODULE)`. - set `CURL_<prototol/feature>_FOUND` for compatibility. - show full list of missing but required `COMPONENTS`. Assisted-by: Derek Huang Fixes #15854 Closes #15858
2024-12-29 22:34:09 +01:00
endif()
check_required_components("@PROJECT_NAME@")
Reference in a new issue Copy permalink