[package] fmt/6.1.2 find_package(fmt REQUIRED) in cmake fails

[TobiSchluter]

find_package(fmt) doesn't work with the fmtlib from conan-center. This seems to be a deliberate choice in the recipe (no cmake_find_package generator) but is fairly inconvenient.

Package and Environment Details (include every applicable attribute)

• Package Name/Version: fmt/6.1.2 (but applies to every version as far as tested)
• Operating System+version: Windows 10 (system independent)
• Compiler+version: VS2019 (again, independent)
• no Docker image
• Conan version: 1.21.1
• Python version: Python 3.7.4

Conan profile (output of conan profile show default or conan profile show <profile> if custom profile is in use)

C:\>"C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\scripts\conan" profile show default
Configuration for profile default:

[settings]
os=Windows
os_build=Windows
arch=x86_64
arch_build=x86_64
build_type=Release
[options]
[build_requires]
[env]

Steps to reproduce (Include if Applicable)

CMakeLists.txt:

include(cmake/conan.cmake) # latest from github
conan_cmake_run(REQUIRES
    fmt/6.1.2

    BASIC_SETUP
    CMAKE_TARGETS
    OPTIONS
    BUILD missing)
find_package(fmt REQUIRED)

Logs (Include/Attach if Applicable)

[cmake] CMake Error at CMakeLists.txt:9 (find_package):
[cmake]   By not providing "Findfmt.cmake" in CMAKE_MODULE_PATH this project has
[cmake]   asked CMake to find a package configuration file provided by "fmt", but
[cmake]   CMake did not find one.
[cmake] 
[cmake]   Could not find a package configuration file provided by "fmt" with any of
[cmake]   the following names:
[cmake] 
[cmake]     fmtConfig.cmake
[cmake]     fmt-config.cmake
[cmake] 
[cmake]   Add the installation prefix of "fmt" to CMAKE_PREFIX_PATH or set "fmt_DIR"
[cmake]   to a directory containing one of the above files.  If "fmt" provides a
[cmake]   separate development package or SDK, be sure it has been installed.**

I prefer using find_package() and then using the usual fmt::fmt target over simply using ${CONAN_LIBS} because it is more explicit and because it allows me to use the same CMakeLists.txt whether I'm using conan or not.

I'd appreciate if this functionality could be reinstated.

Edit: I removed a part about removing cmake etc. Instead, going by the FAQ, it seems that the generator cmake_find_package should be added to the recipe
https://github.com/conan-io/conan-center-index/blob/25f0751b56e7c95bd0e8b23326c88adaf825f945/recipes/fmt/all/conanfile.py

[danimtb]

Hi @TobiSchluter,

Yes, this probably because you are using the generator by default in conan.cmake, which is cmake or cmake_multi. If you want to use the find_package() interface, you should set the additional generator of cmake_find_package as described here https://github.com/conan-io/cmake-conan#generators

Here is the CMakeLists.txt that would make it work with the actual test_package example:

cmake_minimum_required(VERSION 2.8.12)
project(test_package CXX)

include(conan.cmake) # latest from github
conan_cmake_run(REQUIRES
    fmt/6.1.2

    BASIC_SETUP
    CMAKE_TARGETS
    OPTIONS
    BUILD missing
    GENERATORS cmake_find_package)

set(CMAKE_MODULE_PATH ${CMAKE_BINARY_DIR} ${CMAKE_MODULE_PATH})
set(CMAKE_PREFIX_PATH ${CMAKE_BINARY_DIR} ${CMAKE_PREFIX_PATH})

find_package(fmt REQUIRED)

add_executable(${CMAKE_PROJECT_NAME} test_package.cpp)
target_link_libraries(${CMAKE_PROJECT_NAME} fmt::fmt)
set_property(TARGET ${CMAKE_PROJECT_NAME} PROPERTY CXX_STANDARD 14)

Note that you have to set the CMAKE_MODULE_PATH and CMAKE_PREFIX_PATH to the install/build directory so that the findfmt.cmake file is found by CMake.

---

On another note, if you are asking for the CMake find files that were previously packaged, here is an explanation about the topic https://github.com/conan-io/conan-center-index/wiki/FAQ#why-are-cmake-findconfig-files-and-pkg-config-files-not-packaged

[TobiSchluter]

Thank you. So that would generate the package files locally, so to say?

I actually came back to close this bug report, because I wanted to check one thing locally before being confident that this is really reproducible, but I can only do this tomorrow morning. Since you're really responsive and I've therefore already hijacked your time there's no additional cost in keeping this question open until I've checked 😉

Thanks again, let's see if I can confidently exclude local issues tomorrow

[danimtb]

No problem!

I really tried the CMakelists.txt pasted above with latest conan.cmake and it worked. I used Visual Studio 15 2017 Win64 as generator. The only thing you have to care about is the build type to match the one installed by default (It was Debug un my case).

I will close this issue but please comment here or reopen if you find any trouble later when you are able to try it 😄

[TobiSchluter]

Thank you. Adding GENERATORS cmake_find_package seems to indeed do the right thing.What is still confusing me is that it worked the first time I included fmt in my build it simply worked™ and that it still works without the added paths for, say, Catch2.

Anyway, thanks for your help. I'm gonna do things the right way™ from now on!

[danimtb]

Yes, that could be because you are using Catch2/<version>@catchorg/stable or catch2/<version>@bincrafters/stable (new packages generated from this repo won't have @user/channel, like catch2/2.9.2 or catch2/2.11.0). Those packages will likely contain the Find*.cmake files inside, thus find_package() works.

However, as per the explanations in https://github.com/conan-io/conan-center-index/wiki/FAQ#why-are-cmake-findconfig-files-and-pkg-config-files-not-packaged
from Conan we believe that opensource packages should not contain build-system specific files unless they provide a library functionality (helper tool to preprocess files, macro to run tests...).

Instead, Conan is able to abstract the information from package_info() to any build-system via generators, that's why we recommend using the cmake_find_package one in this case.

Thanks a lot for the feedback and hope it helps to understand this decision better.

[TobiSchluter]

soapbox time, this has nothing to do specifically with this "bug report": working with this way of doing things a bit more, I find it inconvenient that this approach changes the library names, e.g. FindPackage(Eigen3) usually gives me a library named Eigen3::Eigen. Using the automatically generated package file the name is Eigen3::Eigen3. So I have to setup aliases in order to use cmakelists that aren't Conan-aware further. I.e. the code is now

set_target_properties(Eigen3::Eigen3 PROPERTIES IMPORTED_GLOBAL TRUE) # necessary for ALIAS
add_library(Eigen3::Eigen ALIAS Eigen3::Eigen3)

I guess I can live with that, but maybe there's a mean to teach the conan recipes how to generate the normal targets instead of autogenerated names?

In the case of Boost it is impossible to do the kind of translation I'm doing above. I understand that Boost is ... unwieldy, actually the original reason for me to try out conan. Why is this kind of translation impossible? Because there is only one big target Boost::Boost left. This is not identical to the usual Boost::boost one gets from findBoost.cmake because the latter only covers header-only libs whereas others have to be referenced as Boost::date_time etc I guess one could alias all of them to Boost::Boost, but that's deifnitely not pretty.

Anyway, thanks for the good work. I still believe that conan makes my life easier.

[danimtb]

Indeed, that is a current limitation of the model that has been discussed previously and it is known as components conan-io/conan#5090. The feature is not developed yet but is a strong topic on the community especially regarding the CMake targets where the implications are evident. You can read more about it on that thread and comment on anything you want. As it is commonly said: We are working on it! 😄

[czoido]

Hi @TobiSchluter
Starting in Conan 1.22 we are setting the IMPORTED TARGETS as GLOBAL so at least you will not have to set_target_properties yourself: conan-io/conan#6438