cmake: expand CURL_USE_PKGCONFIG to non-cross MINGW

[vszakats]

Enable CURL_USE_PKGCONFIG by default for more environments:

• for MINGW targets when not using cross-compilation.
• stop restricting vcpkg to MSVC. (this currently unlocks mingw,
  also unlocked by the update above.)

Also:

• cache CURL_USE_PKGCONFIG in CURLConfig.cmake.
  Suggested-by: Kai Pastor

Follow-up to c555ab4 #14575

---

• add mingw-w64 cross-compilation CI job from Linux and/or macOS. → GHA/windows: add Linux -> mingw-w64 cross-build (cmake, autotools) #14661

[Andarwinux]

Why? Cross-compiling or not, pkg-config is always much better than cmake modules for MinGW. Most cmake modules don't pass private dependencies and cflags at all, which makes them completely useless for static builds.

[vszakats]

pkg-config picks up any native non-cross component by default, breaking builds that were not broken before. pkg-config has no concept of cross-building (I've seen one implementation that does, though that seems like an outlier).

It's a matter of enabling it with CURL_USE_PKGCONFIG=ON in case pkg-config is configured for cross-builds.

[vszakats]

I just noticed that vcpkg also supports MINGW? In such case maybe the condition could be changed to allow pkg-config for any vcpkg compiler?:

-if(UNIX OR (MSVC AND VCPKG_TOOLCHAIN) OR (MINGW AND NOT CMAKE_CROSSCOMPILING))
+if(UNIX OR VCPKG_TOOLCHAIN OR (MINGW AND NOT CMAKE_CROSSCOMPILING))

(perhaps in a separate PR)

[dg0yt]

I just noticed that vcpkg also supports MINGW?

That's why I use it...

---

The CMake config must also use a cache variable, so that users can change it at time of use.

[vszakats]

I just noticed that vcpkg also supports MINGW?

That's why I use it...

I guess that is something difficult to guess from a distance :)

In discussions/proposals, no one said a word about mingw support in vcpkg. This is now on track for the next release.

The CMake config must also use a cache variable, so that users can change it at time of use.

Would you mind posting a diff to illustrate what you mean?

[dg0yt]

The CMake config must also use a cache variable, so that users can change it at time of use.

I realize now that external input is respected in form of if(NOT DEFINED CURL_USE_PKGCONFIG).

Would you mind posting a diff to illustrate what you mean?

My suggestion is to use the same pattern as in CMakeLists.txt.

--- a/CMake/curl-config.cmake.in
+++ b/CMake/curl-config.cmake.in
@@ -23,13 +23,12 @@
 ###########################################################################
 @PACKAGE_INIT@
 
-if(NOT DEFINED CURL_USE_PKGCONFIG)
-  if(UNIX OR (MSVC AND VCPKG_TOOLCHAIN))  # Keep in sync with root CMakeLists.txt
-    set(CURL_USE_PKGCONFIG ON)
-  else()
-    set(CURL_USE_PKGCONFIG OFF)
-  endif()
+if(UNIX OR VCPKG_TOOLCHAIN OR (MINGW AND NOT CMAKE_CROSSCOMPILING))  # Keep in sync with root CMakeLists.txt
+  set(_curl_use_pkgconfig_default ON)
+else()
+  set(_curl_use_pkgconfig_default OFF)
 endif()
+option(CURL_USE_PKGCONFIG "Enable pkg-config to detect CURL dependencies" ${_curl_use_pkgconfig_default})
 
 include(CMakeFindDependencyMacro)
 if(@USE_OPENSSL@)

[vszakats]

@dg0yt Thanks. If I read it right, option() is effectively adding CACHE to set(CURL_USE_PKGCONFIG ...), and keeping existing behavior other than that.

A nit I suggest changing is CURL to @PROJECT_NAME@.

Would you want to open a PR with this?