Conan: [bug] CMake compontent 'filename' produces error in generated find.cmake and causes conflicts when consumer packages

Created on 21 Aug 2020 · 7Comments · Source: conan-io/conan

Earlier this week I upgrade our CI from Conan client 1.27.1 to 1.28.1 after our CI broke on new 1.28 features that caught me off guard.

It's the first time we are consuming the upgrades from #7320 and #7447 en mass

There was a PR merged https://github.com/conan-io/conan-center-index/pull/2545 that is a transitive dependency of mine.

my_project
|___restinio
|    |___expected-lite
|    |___string-view-lite // this is called second and it's not being picked up in my INC_DIRS
|    |___etc
|___etc

So unfortunately we did not have it pinned down by RREV... now I'm in 💩 with my boss, since this is twice in a week, send an 🚑 please. The price of progress.

Doing a lot of digging this morning... the following is not correct.

https://github.com/conan-io/conan/blob/3658bb16d49cb85ae44cb67e76fb45b37b8986ba/conans/client/generators/cmake_find_package.py#L24-L28

According to the CMake docs here

This module provides a function intended to be used in Find Modules implementing find_package(

find_package_handle_standard_args(

Currently because the incorrect values are passed in the generator it seems I am having a collision between two packages which are a valid combination when consumed through the upstream CMake installed files. Thusly the only issue is missing files which are on disk.

It seems there is some missing tests about this corner case, two different package names should be consumable.

Environment Details (include every applicable attribute)

Operating System+version: Windows 10 / Centos 7
Compiler+version: MSVC 2017 and 2019 / GCC 7
Conan version: 1.28.1
Python version: 3.8 / 3.6

Steps to reproduce (Include if Applicable)

conan install restinio/0.6.8.1
CMakeLists.txt: find_package(restinio REQUIRED)

Logs (Executed commands with output) (Include/Attach if Applicable)

CMake configure/generate command

    -- Conan: Using autogenerated Findexpected-lite.cmake
    CMake Warning (dev) at /usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272 (message):
      The package name passed to `find_package_handle_standard_args` (nonstd)
      does not match the name of the calling package (expected-lite).  This can
      lead to problems in calling code that expects `find_package` result
      variables (e.g., `_FOUND`) to follow a certain pattern.
    Call Stack (most recent call first):
      build/Findexpected-lite.cmake:81 (find_package_handle_standard_args)
      /usr/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
      build/Findrestinio.cmake:195 (find_dependency)
      CMakeLists.txt:18 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.

    -- Found nonstd: 0.4.0 (found version "0.4.0") 
    -- Conan: Using autogenerated Findoptional-lite.cmake
    -- Found optional-lite: 3.2.0 (found version "3.2.0") 
    -- Conan: Using autogenerated Findstring-view-lite.cmake
    CMake Warning (dev) at /usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272 (message):
      The package name passed to `find_package_handle_standard_args` (nonstd)
      does not match the name of the calling package (string-view-lite).  This
      can lead to problems in calling code that expects `find_package` result
      variables (e.g., `_FOUND`) to follow a certain pattern.
    Call Stack (most recent call first):
      build/Findstring-view-lite.cmake:81 (find_package_handle_standard_args)
      /usr/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
      build/Findrestinio.cmake:209 (find_dependency)
      CMakeLists.txt:18 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.

build command

.h:32:10: fatal error: nonstd/string_view.hpp: No such file or directory
     #include <nonstd/string_view.hpp>

              ^~~~~~~~~~~~~~~~~~~~~~~~

queue bug

Source

prince-chrismc

All 7 comments

Not to be rude, but because I am invested in Conan's success in an enterprise setting... @memsharded @danimtb if you can please take a look at this issue I just opened, that would be amazing.

prince-chrismc on 21 Aug 2020

So, AFAIK, the CMake code you posted above should be:

find_package_handle_standard_args({filename} REQUIRED_VARS 
                                  {name}_VERSION VERSION_VAR {name}_VERSION)

right?

danimtb on 21 Aug 2020

Yes that's exactly what I would expect!

prince-chrismc on 21 Aug 2020

Even the version variable should be filename for it to be unique

prince-chrismc on 21 Aug 2020

👍1

yeah, taking a look at the CMake documentation I see what is happening there. It might have been an oversight from our side due to the different discussions around cpp_info.filename. We'll fix it as a minor or in the next release.

As a general recommendation, you should not rely on ConanCenter updates in production, or in case you do so, stick to a specific recipe revision to avoid breaking with new PRs introducing changes in ConanCenter.

Anyway, thanks a lot for the report and for taking the time to investigate the issue 👍

danimtb on 21 Aug 2020

yeah, taking a look at the CMake documentation I see what is happening there. It might have been an oversight from our side due to the different discussions around cpp_info.filename. We'll fix it as a minor or in the next release.

:100: It's very confusing which is which. That's perfect, once it's released I will upgrade our CI (hopefully soon).

As a general recommendation, you should not rely on ConanCenter updates in production, or in case you do so, stick to a specific recipe revision to avoid breaking with new PRs introducing changes in ConanCenter.

That's been a rule since we started using Conan however, along the lines of https://github.com/conan-io/conan-center-index/issues/2566, how do I do take into account new dependencies?

One of the advantages of Conan was that I did not worry about the tree, just naming my direct dependencies, but more and more I need to add all of them (which is still produced by Conan but its cumbersome) but worse _know_ all of them as well. It's a heavy time cost, reviewing all the PRs trying to determine which ones impact us, as you know, it time consuming.

I would like to say "I depend on openssl" as opposed to "I depend on openssl and all of it's requirements".

Secondly I can not install --update some packages. Currently it's impossible for me to bump the cache entries of my conanfile.txt without absorbing all the update within the tree.

I will certainly change our policy this afternoon, all dependencies must be RREV'd in a conanfile.txt which will avoid any future problems. smooth :boat: :smile: