[question] Conan Package does not define the library

Hi

Reading the TLDR first might be enough to grasp the issue, but here is a bit of context:

I’ve been using Conan a lot in the past year, and I’m converting all my project & most common external libs to it (conan-center is a very good companion btw).

As there are many ways to approach a package, and things evolved over time, I think I need a bit of a refresher. I decided to switch all of my package to use the cmake_find_package & virtualenv combo to limit the number of files I have to maintain (and staying closer to pure CMake).

I’m not sure if it’s related to switching to cmake_find_package, but I have a linking error to my package from my test_package (or any other package, I just tested to make sure.).

What is strange is that if I remove the test_package, the main package gets exported and inspecting its cache, my includes and library are there, in their respective folders: include & lib. I then noticed a warning from conan when building the test package: Library mtb-core not found in package, might be system one

Looking at the template test_package, I realized you were using imports() to copy the libraries for conan cache to the cmake build, isn’t this handled by cmake_find? To be certain, I added imports into my test_package, and it’s still not working but mtb-core.dylib is in the build folder under lib, I feel like I’m missing something obvious…

TLDR

• Is imports() always required for libraries and headers?
• My package library isn’t exported properly as I have the following warning from building my test_package:

  -- Conan: Using autogenerated Findmtb-core.cmake
  -- Found mtb-core: 0.1 (found version "0.1")
  -- Library mtb-core not found in package, might be system one. <----- This is strange
  

  resulting in a link error: ld: library not found for -lmtb-core What could cause this? How does conan decide what is a lib from the packaged folder? (because it’s there in my case)

Relevant files

the main conanfile.py

from conans import ConanFile, CMake, tools
import os

class MtbCoreConan(ConanFile):
    name = "mtb-core"
    version = "0.1"
    license = "ArtisticLicensev2"
    author = "Mel Massadian"
    url = "-"
    description = "Core C++ Library"
    topics = "melMass"
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True, False]}
    default_options = {"shared": False}
    generators = ["cmake_find_package", "virtualenv"]
    exports_sources = ["src/*", "CMakeLists.txt"]
    requires = ["nlohmann_json/3.9.1", "zlib/1.2.11"]

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def package(self):
        self.copy("*.h", dst="include", src="src")
        self.copy("*.dylib*", dst="lib", keep_path=False)
        self.copy("*.a", dst="lib", keep_path=False)

   def package_info(self):
        # self.cpp_info.libs = tools.collect_libs(self)
        self.cpp_info.libs = ["mtb-core"]

my test package conanfile.py

import os
from conans import ConanFile, CMake, tools

class MtbCoreTestConan(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    generators = "cmake_find_package"

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

    def imports(self):
        self.copy("*.dll", dst="lib", src="bin")
        self.copy("*.dylib*", dst="lib", src="lib")
        self.copy("*.a", dst="lib", src="lib")
        self.copy("*.so*", dst="lub", src="lib")

    def test(self):
        if not tools.cross_building(self):
            os.chdir("bin")
            self.run(".%smtb-example" % os.sep)

• I’ve read the CONTRIBUTING guide.

[lasote]

Hi! I strongly recommend using the new CMakeDeps generator in addition to the CMakeToolchain instead of the cmake_find_package. They are tagged as “experimental” but they are here to stay and replace all the cmake generators in Conan 2.0. You can find the documentation here: https://docs.conan.io/en/latest/reference/conanfile/tools/cmake.html

Said that I don’t really understand your issue, the “lib” prefix shouldn’t be an issue. If you could provide a package to test maybe we could help.

[melMass]

Hi! The packaging is exactly the same, I don’t know what you mean.

Ok ignore me ahah, I think I’ve just barely used the possibilities of cpp_info and this doc revealed them to me

https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmakedeps.html#properties I’m not sure of when I should rely on conan’s find_deps()

Why we did that component split?

Very interesting, ok I see the huge benefit of this approach.

---

I think I need to re-read the new documentation fully as I have missed a few important updates it seems. I currently cannot isolate my original issue as I’m in the middle of a huge refactoring so I will close this issue and open a proper one with an isolated test case if I have a similar issue.

Thanks a lot for your answers @lasote