community: Probably invalid libcurl findCURL.cmake

Description of Problem, Request, or Question

Hi @theirix, @solvingj @uilianries , I’m making some tests with the new Conan 1.4 cmake generators and the libcurl library to prepare a blog post explaining them.

I found an issue, the custom FindCURL.cmake file (probably inherited from my original recipe) is assuming that the variables ${CONAN_INCLUDE_DIRS_LIBCURL} and ${CONAN_LIB_DIRS_LIBCURL} are present, but it is only true if you are using the cmake generator and including the conanbuildinfo.cmake file.

https://github.com/bincrafters/conan-libcurl/blob/stable/7.52.1/FindCURL.cmake

I’m wondering if we still want to keep that customized FindCURL.cmake file. Since some time ago, I stopped to provide custom find package scripts, because the ones from the cmake installation become inaccesible, and the recipe gets outdated with the improvements that kitware introduces (for example, the target creation). In other recipes where the original find_package was not finding the libraries (because of different names ,corresponding to not tested by kitware configurations) I decided to package the libraries renaming first.

What do you think? Now the find_package is broken unless you specify the cmake generator, it doesn’t sound good.

Package Details (Include if Applicable)

Package Name/Version: libcurl/7.52.1
Operating System: OSX high sierra
Compiler+version: apple clang 9.1

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 16 (5 by maintainers)

Commits related to this issue

Do not package FindCURL.cmake Refs bincrafters/community#297 — committed to bincrafters/conan-libcurl by theirix 6 years ago

Most upvoted comments

Done!

theirix on Jun 7, 2018

@lasote , thank you! I checked the build on Linux too – it works well. Removed finder in the branch testing/7.52.1 (except the OpenSSL upgrade, it should go to different one).

theirix on Jun 5, 2018

In 1.4 we provide two new generators for cmake, extracted from “https://blog.conan.io/2018/05/30/New-conan-release-1-4.html”:

New cmake_paths and cmake_find_package generators
After all the feedback collected regarding CMake integration, we focused the development with the goal of providing a transparent way to integrate CMake relying on find_package(), especially useful for Conan package consumers.

This led to two different generators:

cmake_find_package generator creates one Find<package_name>.cmake file for each dependency. This will make each find_package in you CMakeLists.txt point to the dependency solved by Conan after a conan install. Read more.

cmake_paths generator creates a conan_paths.cmake file with CMAKE_MODULE_PATH and CMAKE_PREFIX_PATH variables adjusted to the dependencies folders. This also allow users to integrate Conan without modifying the CMakeLists.txt: cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_paths.cmake. Read more.

So, the custom FindCURL.cmake makes no sense, especially if it is attached to the cmake generator, because it won’t work unless you are using it.

lasote on May 31, 2018

Sorry, forgot this issue.

Could you please link to the idea of the cmake change in Conan 1.4?

I don’t remember why we are including this. It’s here since the recipe imported from lasote/conan-libcurl. FindCURL.cmake is available as a cmake standard module even for the ancient cmake 2.8.0. Of course it’s better to have a standard module and I prefer to drop those from recipes.

I’ll try to rebuild recipes dependent on libcurl on an isolated machine without recipe-provided findcurl.cmake.

theirix on May 31, 2018