Skip to content

FindCURL: Try to find CURLConfig.cmake

Charlie Barto requested to merge barcharcraz/cmake:chbarto/fix_findCURL into master

FindCURL currently first tries pkg-config, then tries to guess based on library name.

On Windows this is rough, since the pkg-config file is only output from the autotools build (and most windows devs don't have a copy of pkg-config in any case), and when guessing, FindCURL really can't figure out things like if the curl is static, or what libraries it depends on (for example on windows it may be Ws2_32.lib,Crypt32.lib or Ws2_32.lib,OpenSSL::Crypto,OpenSSL::SSL or Ws2_32.lib,Crypt32.lib,Wldap32.lib). These days most versions of libcurl are built on windows using libcurl's cmake build system, and that build system will generate a CURLConfig.cmake file that knows how to handle these things.

Since the autotools build doesn't output the CURLConfig.cmake file users are not able to just always use find_package(CURL CONFIG), since that won't work for most linux system packages.

This PR updates FindCURL.cmake to try and use that config file in the same way FindBoost.cmake does today (for boost).

Some questions I'd love answered:

  • currently the module will fail if the only working method of finding curl was the CURLConfig.cmake file, and the user specified components for curl. If the user specifies components for curl the attempt to use CURLConfig.cmake will essentially always fail. IMO this is something that should be fixed upstream by adding components to CURLConfig.cmake. Should the module bail immediately in this case (curl found in config-mode, but no components found) or go on to continue trying to find CURL?
  • the CURL_NO_CURL_CMAKE variable was added to disable the config-mode search, if desired. Is this a good name? it's modeled after the one in FindBoost, but maybe FindCURL_NO_CURL_CMAKE would be better?

Topic-rename: FindCURL-cmake-package

Edited by Brad King

Merge request reports