Conan: aggregate multiple packages to be used indepentendly

I am currently using Conan as an “helper tool” for my main project: I have created a conanfile.py that builds all my dependencies and imports them to the current folder. The goal in the end is to archive and redistribute this folder to our multiple machines and just tell CMake that everything is in there.

However, here’s the catch: I want this archive to not be dependent on Conan. Our CMakeLists.txt are using Find_Package() and I really want this to work non intrusively. So far, I have managed to get something working, however, my main problem is CMake integration.

Here’s how I want to create my archive:

mkdir build
conan install <path to my conanfile> -if build
tar cf archive.tar build

So far, I have managed to properly copy all my dependencies in the correct directories (build/bin contains all binaries, build/include all includes and so on)

My only problem now is using CMake. I tried using cmake_paths and cmake_find_package generators but they all point to the conan cache on my machine.

I then tried the deploy generator, which seems to be very close to what I want to achieve. However, I cannot figure out how to generate cmake files from the directory I just deployed to.

I found the generate() method but I havent had much success with it.

Do I need to implement this externally ? Like patching the files created by the cmake generators ? Or is there a cleaner way ?

Thanks

Edit: Just want to clarify: I do not want to use conan for anything else than simply building my dependencies. It is installed on our main server that hosts the gitlab CI/CD that will build the binaries. It is not used by anything else.

Answer

This question has been answered by Conan’s co-founder james here: https://github.com/conan-io/conan/issues/9874

Basically:

  • Use the CMakeDeps generator instead of cmake / cmake_find_package
  • Patch the resulting cmake config files at install time inside the generate() method from the main conanfile.py
  • Edit recipes accordingly (but should be fine most of the time)