CMake find-package support

[mirzachi]

This PR improves CMake integration of the library.

I was surprised that one cannot simply download, build, install the library on the system and then simply integrate the library within other project via the standard CMake find-package utility. This PR adds this feature. For instance, now one can import the library in other CMake project like this:

CMakeLists.txt

cmake_minimum_required(VERSION 3.20)
project(cpr_client)

set(CMAKE_CXX_STANDARD 17)

find_package(cpr REQUIRED)
if (cpr_FOUND)
    message(STATUS "Found cpr: ${cpr_CONFIG} (found version ${cpr_VERSION})")
endif ()

add_executable(cpr_client main.cpp)

target_link_libraries(cpr_client PRIVATE cpr::cpr)

main.cpp

#include <iostream>
#include <cpr/cpr.h>

int main(int argc, char** argv) {
    cpr::Response r = cpr::Get(cpr::Url{"https://api.github.com/repos/whoshuu/cpr/contributors"},
                               cpr::Authentication{"user", "pass"},
                               cpr::Parameters{{"anon", "true"}, {"key", "value"}});
    std::cout << r.status_code << std::endl;                  // 200
    std::cout << r.header["content-type"] << std::endl;     // application/json; charset=utf-8
    std::cout << r.text << std::endl;                         // JSON text string
}

Note that I handle CURL dependency in cprConfig.cmake.in. This is why one has to only include find_package(cpr REQUIRED).

This feature is feasible only if CPR_FORCE_USE_SYSTEM_CURL is set.
Otherwise, you download libcurl in-source and link against its targets.
This is a problem since you have to not only export and install cpr CMake target, but also all targets that cpr target links against.
In this case, curl_int. Further, its dependecies would have to be handled and exported, etc.
In other words, CMake is not a helpful tool for this use case.

[KingKili]

First thanks for the PR.
It also looks very good. I am currently thinking if we should also force the usage of CPR_USE_SYSTEM_GTEST.

[mirzachi]

Enforcing CPR_USE_SYSTEM_GTEST is not necessary for the provided find-package support. CMake output artifacts for tests are binary executables that you do not install anyways. Since tests are built within the project, all dependencies are resolved within the project already.

USE_SYSTEM_GTEST is the variable that you check against in the later if statement and not CPR_USE_SYSTEM_GTEST.
This might be a bug in CMakeLists.txt!

[KingKili]

Enforcing CPR_USE_SYSTEM_GTEST is not necessary for the provided find-package support. CMake output artifacts for tests are binary executables that you do not install anyways. Since tests are built within the project, all dependencies are resolved within the project already.

That is true, but I was afraid that gtest itself would be installed by default with cpr. But this option is off by default, therefore it should be fine.

USE_SYSTEM_GTEST is the variable that you check against in the later if statement and not CPR_USE_SYSTEM_GTEST.
This might be a bug in CMakeLists.txt!

Thanks for pointing out, I will have look at it.

[KingKili]

I just tried it locally, and it worked great. Therefore, I will merge your PR. Thanks for the great work!

[ronytigo]

I get "Could NOT find CURL (missing: HTTP) (found version "7.80.0")"

[sachabest]

what's the logic behind requiring the system CURL be used in order for CPR to cmake --install properly? Note that if you fetch CPR with FetchContent and do a variant of cmake --install thereafter, you do actually end up with the "fetched" libcurl installed where you'd expect, including the CMake targets file for CURL itself. The only thing missing from this installation method is the CMake targets file for CPR, which is explicitly flagged behind the SYSTEM_LIBCURL flag in this PR.