[question] The thing I've never understood with Conan and CMake

[gpxricky]

What is your question?

Hi,

we are trying to use Conan for few years now, but I'm always struggling with one thing. We use Conan in combination with CMake. In CMake we have lots of targets, e.g. the regular build, the tests, some documentation to be generated, a static code analysis and much much more. Our developers usually work on a single CMake target for some while (sprint), maybe on 2-3, but definitely not all of them. However, I can't find a good way to map those CMake targets to my Conan recipe. That's the reason why Conan is just used to create the final build, but the development is only done using CMake (so Conan is just there to fetch the dependencies). What is the idea from the Conan developers regarding such a development process? Is our development process correct? How to handle different targets that we usually also want to split into different CI tasks when running a CI build? Is there some hidden Conan magic we haven't figured out yet?

Many thanks for your feedback.

Best regards, gpxricky

Have you read the CONTRIBUTING guide?

• [x] I've read the CONTRIBUTING guide

[memsharded]

Hi @gpxricky

Thanks for your question.

I am not very sure what you mean. If you use Conan for dependencies, then whatever you do with your CMake project you can do it with your CMake project, nothing changes. You can have the targets that you want and use them as you want, Conan just download dependencies and injects them so the find_package() will find them.

You don't need to map those targets to anything in Conan if you don't want, and typically things like tests are not mapped to Conan except a call to cmake.test() or cmake.ctest() in case you want to be able to run tests also from Conan flows.

[memsharded]

Hi @gpxricky

Any clarification for the above comment? Thanks.

[gpxricky]

Hi @memsharded,

sorry for late feedback. At the end the question is whether using features like conan build is really useful in such a scenario or if it makes more sense to use Conan to download the dependencies and to create the final Conan package, but everything else shall be done in good old CMake?

Because, as you already mentioned, propagating all useful targets from CMake to Conan does not really make sense. So our developers will then use Conan just to get the correct dependencies and will more or less work on CMake only and just the final CI build that creates the Conan package will use "full Conan" functionality.

Best regards, gpxricky

[memsharded]

sorry for late feedback. At the end the question is whether using features like conan build is really useful in such a scenario or if it makes more sense to use Conan to download the dependencies and to create the final Conan package, but everything else shall be done in good old CMake?

The reality is that it depends, it is very often a matter of taste, opinions, different project constraints, etc.:

• There are quite a few users that love the conan build command, as it does everything, the installation of dependencies, the configuration of the project, the build, etc, and it does it irrespective of the build system, so for example for organizations that have a mix of autotools and cmake projects, it is very convenient to be able to build all projects in exactly the same way. It can also be good if needing to build different platforms, cross-building, etc, with using profiles. There are tweaks/confs to activate/deactivate testing, etc. After the first initial build, it is perfectly possible to also open the IDE and continue working from the IDE.
• There are users that prefer more control from CMake, to be able to command from CMake different aspects of the build, like individual testing, or customizations that are driven by direct CMake arguments. In fact, the "canonical" package usage flow is considered the conan install + cmake --preset flow nowadays.

Because, as you already mentioned, propagating all useful targets from CMake to Conan does not really make sense. So our developers will then use Conan just to get the correct dependencies and will more or less work on CMake only and just the final CI build that creates the Conan package will use "full Conan" functionality.

Yes, this would be a case of the second point above. And it is perfectly fine to use only conan install for development and not conan build, which was added mostly as a convenience for users in the first case. Then, as you said, development happens 99% with conan install + cmake, then only when the dev job is done, the conan create creates the packages, sometimes the developer can do a local quick test to check everything works well in the package creation, but usually is the CI the one that does the create + conan upload to the servers to make the packages available.