cmake: fix building with CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON

[vszakats]

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: cmake: fix downstream app build issue when curl dep library paths defined #20764
  Follow-up to 16f073e cmake: define dependencies as IMPORTED interface targets #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 fcde8d7 cmake: minor improvements to integration test framework #20773

Reported-by: Valerie Snyder
Fixes #20729

---

https://github.com/curl/curl/pull/20784/files?w=1

• GHA/distcheck: add test case.
• delete test setting from CMakeLists.txt.
• perhaps merge cmake: fix downstream app build issue when curl dep library paths defined #20764 to fix the issue when consuming libcurl.

The CI confirms a number of fallout when this custom option is set:
https://github.com/curl/curl/actions/runs/22546213460 macOS
https://github.com/curl/curl/actions/runs/22546213435 Linux
https://github.com/curl/curl/actions/runs/22546213465 Windows

[vszakats]

This may also be a way to add support to curl Find modules for using cmake CONFIGs
(in addition to existing pkg-config and raw/manual detection). Which in turn may
help with static builds. When using MODULE, it's guaranteed to hit curl's Find
module first without using CONFIGs, then the Find module may possibly use a
find_package() limited to CONFIGs, effectively "chaining" them. Then the curl
logic needs to create aliases to map the found targets to the CURL:: namespaced
ones, and possibly do other things to make those targets compatible with the
rest of the build. I haven't made tests, so it's all theory at this point.

Ref: #20013, #19117 and #19156.

[vszakats]

@aisle-analyzer augment review

[aisle-research-bot]

🔒 Aisle Security Analysis

✅ We scanned this PR and did not find any security vulnerabilities.

_{Aisle supplements but does not replace security review.}

---

Analyzed PR: #20784 at commit 5122d1b

_{Last updated on: 2026-03-02T17:37:54Z}

[Copilot]

Pull request overview

This PR adjusts curl’s CMake dependency discovery to behave correctly when users enable CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON, ensuring curl’s build and exported CURLConfig.cmake consistently use curl’s bundled Find*.cmake modules (so expected CURL::<dep> targets are created).

Changes:

• Force find_package(... MODULE ...) for dependencies that have curl-provided Find<Dep>.cmake modules (both in-tree build and exported config consumption).
• Update the exported CMake/curl-config.in.cmake to use find_dependency(... MODULE) for these dependencies while preserving CONFIG-based behavior for OpenSSL and ZLIB.
• Add a Windows distcheck job that builds and consumes curl with CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
CMakeLists.txt	Forces MODULE-mode package discovery for curl-bundled Find modules so CURL::<dep> targets are reliably defined.
CMake/curl-config.in.cmake	Forces MODULE-mode dependency discovery when consuming curl via find_package(CURL), avoiding CONFIG packages that don’t create CURL::<dep> targets.
CMake/Macros.cmake	Updates curl_dependency_option() to prefer MODULE finds for curl-bundled deps, with an explicit exception for ZLIB.
.github/workflows/distcheck.yml	Adds a Windows integration test that exercises build+consume under CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[augmentcode]

🤖 Augment PR Summary

Summary: This PR hardens curl’s CMake build/packaging against builds where CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON would otherwise select upstream Config.cmake packages and skip curl’s own Find.cmake logic/targets.

Changes:

• Force module-mode discovery (find_package(... MODULE)) for curl-managed dependencies in CMakeLists.txt and CMake/Macros.cmake (with ZLIB intentionally left flexible).
• Update the installed curl CMake package (CMake/curl-config.in.cmake) to use find_dependency(... MODULE) for the same dependency set, ensuring expected CURL::* targets are created when consuming curl.
• Add a distcheck workflow job to build and then consume curl via find_package with CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON enabled (Windows matrix).

Technical Notes: This keeps curl’s custom Find* modules in the resolution path even when users prefer config packages globally, avoiding successful-but-incomplete dependency discovery that would omit required imported targets.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. No suggestions at this time.

Comment augment review to trigger a new review at any time.