# Linking to curlcpp (a C++ curl wrapper)

**URL:** <https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677>\
**Category:** Code\
**Created:** [May 16, 2022, 8:34pm UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677 "2022-05-16T20:34:48Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![rturrado](https://discourse.cmake.org/user_avatar/discourse.cmake.org/rturrado/32/3499_2.png) [@rturrado](https://discourse.cmake.org/u/rturrado)\
**Post date:** [May 16, 2022, 8:34pm UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677/1 "2022-05-16T20:34:48Z")

</div>

I’m trying to link [curlcpp](https://github.com/JosephP91/curlcpp), a C++ [curl](https://curl.se/download.html) wrapper, to a library of my own.

My idea was to:

1. FetchContent\_Declare both curl and curlcpp.
2. FetchContent\_MakeAvailable both of them as well.
3. Link libcurl.lib and curlcpp lib to my library.

I’m getting though an error saying that curlcpp needs `CURL_LIBRARY` variable to be set.

- Is there any way to 1) set `CURL_LIBRARY` to wherever the build process is going to leave libcurl.lib, and 2) have it available for curlcpp compilation? I understand a `set(CURL_LIBRARY <path to libcurl.lib>)` should suffice.
- I know curl sources are downloaded to `${curl_SOURCE_DIR}`. Can I know where the output libcurl.lib will be placed? Is there a `${curl_BINARY_DIR}`?

Here’s what I understand can be the relevant code from my CMakeLists.txt files.

```auto
cmake_minimum_required(VERSION 3.5)

project(my_project
    LANGUAGES C CXX # C is needed for curl
)

FetchContent_Declare(curl
    URL https://curl.se/download/curl-7.83.1.tar.gz
)
FetchContent_Declare(curlcpp
    GIT_REPOSITORY https://github.com/JosephP91/curlcpp.git
    GIT_TAG "55bc50c244ecb5a14ac21b3b2e2931267a5bb802"
)
FetchContent_MakeAvailable(curl curlcpp)

target_link_libraries(lib_${PROJECT_NAME}
    libcurl
    curlcpp
)

```

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [May 16, 2022, 9:07pm UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677/2 "2022-05-16T21:07:44Z")

</div>

You may be able to set it to the target that `curl` makes for you to use (`libcurl` it appears).

Cc: @craig.scott

---

<div class="post-metadata">

**Author:** ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)\
**Post date:** [May 17, 2022, 5:16am UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677/3 "2022-05-17T05:16:22Z")

</div>

There’s also the “Curl for People” project, which you can find here:

> **[GitHub - libcpr/cpr: C++ Requests: Curl for People, a spiritual port of...](https://github.com/libcpr/cpr)**
>
> C++ Requests: Curl for People, a spiritual port of Python Requests. - GitHub - libcpr/cpr: C++ Requests: Curl for People, a spiritual port of Python Requests.

I’ve embedded that into a larger project hierarchy with FetchContent before. I upstreamed a couple of minor patches to enable that to be done cleanly, and they are part of the official releases now, so I’d expect a fairly smooth path.

The problem you are facing with `curlcpp` is that it wants to bring curl into the build with `find_package()`, but you are trying to bring curl into the build with `FetchContent`. There is a feature coming in CMake 3.24 which would allow you to do this cleanly (see [MR 5688](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5688)), but at the moment, this mixture of methods requires some hacking around one or the other to make it work. Basically, you would have to either force the `find_package()` call to pick up a dummy `Findcurl.cmake` or `curl-config.cmake` that you put somewhere, or abandon using FetchContent bringing in curl and require it to be provided by something outside of CMake.

---

<div class="post-metadata">

**Author:** ![rturrado](https://discourse.cmake.org/user_avatar/discourse.cmake.org/rturrado/32/3499_2.png) [@rturrado](https://discourse.cmake.org/u/rturrado)\
**Post date:** [May 17, 2022, 12:05pm UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677/4 "2022-05-17T12:05:55Z")

</div>

Thanks for your response. I did try quite a few things, one of them doing a `target_link_libraries(curlcpp INTERFACE ${curl_BINARY_DIR}/lib/libcurl.lib)` and then linking my library to curlcpp, but no of them work.

---

<div class="post-metadata">

**Author:** ![rturrado](https://discourse.cmake.org/user_avatar/discourse.cmake.org/rturrado/32/3499_2.png) [@rturrado](https://discourse.cmake.org/u/rturrado)\
**Post date:** [May 17, 2022, 12:07pm UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677/5 "2022-05-17T12:07:42Z")

</div>

I’ll definitely give this libcpr/cpr a go.

Many thanks for the explanation of my issue!

---

<div class="post-metadata">

**Author:** ![benthevining](https://discourse.cmake.org/user_avatar/discourse.cmake.org/benthevining/32/1924_2.png) [@benthevining](https://discourse.cmake.org/u/benthevining)\
**Post date:** [May 17, 2022, 7:15pm UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677/6 "2022-05-17T19:15:49Z")

</div>

This new integration between FetchContent and find\_package sounds amazing! I think it would make the job of a package manager much easier to integrate with CMake.

Is this feature going to be in 3.24.0?

---

<div class="post-metadata">

**Author:** ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)\
**Post date:** [May 17, 2022, 10:00pm UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677/7 "2022-05-17T22:00:31Z")

</div>

Yes, it is already merged, so should be in CMake 3.24. There’s other associated work too relating to package manager support which should make it in as well (I’ll be putting up that change for review this week).

---

<div class="post-metadata">

**Author:** ![benthevining](https://discourse.cmake.org/user_avatar/discourse.cmake.org/benthevining/32/1924_2.png) [@benthevining](https://discourse.cmake.org/u/benthevining)\
**Post date:** [May 17, 2022, 10:00pm UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677/8 "2022-05-17T22:00:53Z")

</div>

awesome, exciting!

---

<div class="post-metadata">

**Author:** ![rturrado](https://discourse.cmake.org/user_avatar/discourse.cmake.org/rturrado/32/3499_2.png) [@rturrado](https://discourse.cmake.org/u/rturrado)\
**Post date:** [May 20, 2022, 5:15pm UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677/9 "2022-05-20T17:15:13Z")

</div>

May you point me to an example of a dummy FindXYZ.cmake file?

I’ve seen that, in my project, I have a few other cases where I have the same issue.

For example, [PDF-Writer](https://github.com/galkahana/PDF-Writer) project adds libpng and zlib as submodules, but [PNGwriter](https://github.com/pngwriter/pngwriter) just relies on those two libraries being installed.

I understand I can add Findzlib.cmake and Findpng.cmake dummies so that CMake wouldn’t complain when processing PNGwriter’s CMakeLists.txt file (I got to that point just by using two empty dummies).

But I also understand I will have to do some work in those dummies:

1. Set some variables: zlib\_FOUND, zlib\_INCLUDE\_DIRS, zlib\_LIBRARIES?
2. Make them point to wherever that include dir and lib are going to be generated: pdfwriter\_SOURCE\_DIR/Zlib and pdfwriter\_BINARY\_DIR/Zlib/Zlib.lib?

---

<div class="post-metadata">

**Author:** ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)\
**Post date:** [May 20, 2022, 10:22pm UTC](https://discourse.cmake.org/t/linking-to-curlcpp-a-c-curl-wrapper/5677/10 "2022-05-20T22:22:33Z")

</div>

I don’t have a suitable example file to point you at. Taking curl as an example, you would have to find an existing `curl-config.cmake` or similar file from an installed curl. That should show you all the things it normally defines (targets and variables). Anything that your project uses from that are the things that your own dummy `Findcurl.cmake` file would have to define somehow. I know that’s a bit vague, but that’s the best I can offer right now.