Well, as of right now, it currently isn’t possible to use Conan in a non-intrusive way. That is, using it for fetching dependencies without adapting the build configuration to it. I’ve opened up a pull request (as well as a fix) for this issue here [1].
I’ve implemented pure CMake-based package management solutions based on ExternalProject_Add() (using a Superbuild approach) in the past as well as using Conan for managing dependencies currently for a client of mine. Based on my experience, I’m confident that really the only reason to use Conan is that it solves the persistence of binary artifacts for you. Since Conan uses a client/server architecture you typically have something like an Artifactory server where Conan is able to store and fetch precompiled packages for you. Currently, CMake doesn’t offer something like this, but I think it should be trivially to implement (think of CDash but for storing binary artifacts). One issue I have with Conan is that you are forced to duplicate some of your build logic that in my point of view really belongs to the build system and not to your package management solution. [1] https://github.com/conan-io/conan/issues/4467 <https://github.com/conan-io/conan/issues/4467> -- Kai Wolf Kai Wolf - SW Consulting www.kai-wolf.me <http://kai-wolf.me/> XING <https://www.xing.com/profile/Kai_Wolf14> · LinkedIn <https://www.linkedin.com/in/kw0lf/> · GitHub <https://github.com/NewProggie> > Am 19.02.2019 um 11:56 schrieb Craig Scott <craig.sc...@crascit.com>: > > > > On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona <tjwrona1...@gmail.com > <mailto:tjwrona1...@gmail.com>> wrote: > I have been working on a new C++ project and I am trying to decide whether I > should use CMake as my package management system or if I should use a > dedicated package management tool such as Conan. > > For more information on Conan see: https://conan.io/ <https://conan.io/> > > I am trying to understand the main difference between using Conan to manage > dependencies vs using CMakes "FetchContent" module. Are there any compelling > reasons to prefer something like Conan? > > Excellent question, one that I think deserves a more detailed answer than I > can provide here, but I'll try to hit the main points as I see them. > > Personally, I think there is no "right answer" or "one size fits all" when it > comes to package management for a CMake project. What works well for one > situation, person or project may not be as convenient or suitable for > another. There are competing needs and views, some of which are personal > preferences, others are hard requirements from things like OS distribution > policies for packaging. Even just the maturity of a project can have a big > influence on how developers may prefer to handle its dependencies and handle > it as a dependency of other projects. > > The key thing for me is that the developer should ideally have choices when > it comes to this area. If a project hard-codes that its dependencies must > come from a particular provider (whether that be Conan, Hunter, vcpkg or some > other system), this might not be compatible with what the developer's > situation allows. You would need to weigh up whether it makes sense to lock > the developer into a particular package manager if they want to use your > project or not. An inappropriate choice here can mean lower adoption of the > project as some may reject it for consideration based on this point alone. > > If instead a project relies only on find_package() to find its dependencies, > then it is up to the developer to ensure they are all available. This could > be done using whatever package manager the developer finds convenient, or > they could build the dependency projects from source individually or they > might set up a superbuild parent project that builds the dependencies in the > required order and makes dependees available to dependers. This gives good > flexibility at the cost of more responsibility on the developer than perhaps > some would want (again, it will be highly situation-dependent). > > A drawback with find_package() is that it assumes you actually have a > packageable project. For a variety of reasons, this may not be the case. > Consider a large, complex project in its early stages and where multiple > teams are working on different subprojects which all get combined into some > larger whole. Each of the subprojects may need to be able to build on their > own with their own smaller subset of dependencies, but they also need to be > able to be incorporated into a larger build (think of different teams working > on core toolkits, rendering engines, different algorithm strategies, multiple > GUI applications, backend components, etc). No-one may know yet how it should > get packaged up and everyone might be focused on just getting a minimal > viable prototype up and running as a technical demonstrator. For a case like > that, neither find_package() nor a package manager really fits the workflow. > In this situation though, FetchContent is a perfect fit, since it doesn't > require any packaging to already be in place, it needs no external tools > other than CMake and it gives each project precise control over its > dependencies down to the individual commit to bring in for each one. > > With the above in mind, perhaps the following few questions may be helpful in > clarifying what your constraints are and maybe steering you more toward one > way or the other: > Will the project be incorporated into a Linux distribution at some point (not > just be installed on Linux, but be part of the actual Linux distribution as > provided by its own native package manager)? If so, I would expect this would > pretty much eliminate using any package manager and instead require that you > use find_package() to find all dependencies. > Are any of the dependencies of the project using a build system other than > CMake? If so, they tend to take a bit more work to incorporate into a build > via ExternalProject or FetchContent. If you can assume the developer provides > those somehow, bringing them in by find_package() shifts responsibility for > building them from the project to the developer (or whatever package manager > they choose to use). This might be anywhere from entirely appropriate to > entirely problematic depending on who your intended audience is. > How many dependencies does the project have and what is the maturity of each > one? Will the project need to update any of those dependencies often (are > they also being actively developed, do you need to follow recent work in > them)? What will be the impact on developers working on the project when > these dependencies need to be updated (how easy is it for them to update, > what assumptions are you making about their development environment and > tools)? > What breadth of platforms, compilers and CMake generators do you want to > support? The bigger this set, the more it may drive you towards building > dependencies from source rather than relying on having pre-built packages > available to you. > Do you want developers to be able to use tools like sanitizers, perform code > refactoring across projects or have source code visibility into dependencies > within their IDE tools? FetchContent supports all of these requirements quite > naturally, but doing so for the other methods it may be more difficult. > How will you manage repeatability of building past releases? Will you be able > to build a year old release again if you update a build slave? In particular, > what assumptions are you making about a CI system's build slaves and what > dependencies they have installed (can you have multiple versions of any given > dependency available at once, whether that be at a known path or via whatever > package manager(s) you choose to use)? > > On a side note, this is an area I'm increasingly thinking about these days > (I'm the author of the FetchContent module). I'm interested in hearing > peoples' views on dependency management and building an understanding of what > works for people and what doesn't. If you want to send feedback my way, do > feel free to get in touch. > > -- > Craig Scott > Melbourne, Australia > https://crascit.com <https://crascit.com/> > > Get the hand-book for every CMake user: Professional CMake: A Practical Guide > <https://crascit.com/professional-cmake/> > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake
signature.asc
Description: Message signed with OpenPGP
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
