[question] Best practice for installing many package artifacts to a common runtime location

[dataless-patch]

What is your question?

Say I have packages a, b, c, d, etc., and I want to take the libs and exe's from them and have them be installed in a specified directory where I can then run/test them. Assuming all packages were built using cmake (deps, toolchain, layout, etc.), would it then be best to just have cmake handle this during the install stage? I've been wondering if deployers would be more suited to handling this?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @dataless-patch

Thanks for your question.
The first point would be to consider if you actually need to deploy/copy things to test it. In general this would be way less efficient than using a virtualenv that defines the right paths to the exes/dlls. In most cases the deployments should only happen when you really need to distribute things outside of Conan

Then, the --deploy deployers were created exactly for this purpose, to copy files and put them somewhere together in user space. Generators and custom generators (Conan 2.0.5 will add global generators back) can also be used to create auxiliary files, summaries/manifests, and other automation around it, which could help. In general it is way easier to automate things in Python than in CMake.

The CMake install capabilities might be a bit limited for the dependencies, and there are also some possible limitations due to lack of information and definitions of CMake targets of dependencies for shared libraries. Though there are planned some improvements in CMakeDeps generator for this, this will take time. So probably the deployers approach would be better at this moment.

[dataless-patch]

Hi @memsharded, thanks for getting back to me.

I had another deployer-related question (if you don't mind). I've been able to mostly do exactly what I want in terms of building a user-space application folder using a custom deployer; however, I'm wondering if there's a conan-way to have each recipe describe how it wants to be deployed individually (maybe in its own recipe) so that I could have some libs and executables from certain packages deploy into one folder, and maybe some other libs and executables deploy into a different folder without having to write this logic in a custom deployer?

I read in the 1.X docs that there was a deploy() method, but invoking it required a conan install with an explicit package reference which seemed like it would make automating deployment less practical if I'm understanding that correctly (apologies if I'm not).

[memsharded]

You are right, this was a recipe thing in Conan 1.X, but we realized that it had a bunch of issues and unexpected side effects.
If you prefer to maintain the deployment logic in a recipe you can do something like this in 2.0:

• Create a conanfile.py, and you can call it something like myappdeploy/1.0.
• In that recipe you add the requires you want to the things you want to deploy, like myapp/1.0
• You write the logic of the deployment in your generate() method. You can do copy() there, and any other kind of manipulation. The code would be practically identical to what you have in your custom deployer deploy() method

With that you should be able to export/create that recipe and use it to deploy your applications, just by installing that conan install --requires=myappdeploy/1.0

[memsharded]

There have been some progress since then in Conan 2:

• Add built in runtime deployer #15382 has been merged for next Conan 2.5
• Recipes also re-learned in Conan 2 a new deploy() method, that can be triggered by a --deployer-package command line argument: https://docs.conan.io/2/reference/conanfile/methods/deploy.html#deploy

I am closing this question as solved, but please don't hesitate to create new tickets for any further question or issue you might have. Thanks for the feedback!