Clion Conan

Clion

This is a bit of a battle report of migrating the dependencies in my C++ projects to use the conan package manager.
In the past weeks I have started to use conan in half a dozen both work and personal projects. Here’s my experiences so far.

Click on the CLion icon and go to preferences Build, Execution, and Deployment Conan. Add the path to the Conan executable and click OK. If you don’t know this, go to your terminal and run “where conan” to view the path. Step 2: Update the CMakeLists.txt file. Code::Blocks, Microsoft Visual Studio, and CLion are probably your best bets out of the 16 options considered. 'Cross platform' is the primary reason people pick Code::Blocks over the competition. This page is powered by a knowledgeable community that helps you make an informed decision. In this guest blog post Javier G. Sogo from JFrog shares how to start with Conan package manager in CLion. Sogo @jgsogo Software Engineer at JFrog After several years of C development, I moved to Python to learn the best practices and tools. Now I’m back building Conan, the C/C package manager. Writing a C p. Conan package manager integration with CLion. CLion 2020.3 with a configured WSL toolchain; CMake 3.10.2; Conan 1.32.1; GLFW 3.3.2, from the conan-center remote; I can manage to run the Getting started example of conan without any issues, but installing GLFW seems to be a bit more involved than poco. I can locate the desired header in the.conan directory, but for some reason it is not.

The first real project I started with was my personal game project. The “before” setup used a mixture if techniques to handle dependencies and uses CMake to do most of the heavy lifting.
Most dependencies reside in the “devenv”, which is a separate CMake project that I use to build and bundle the dependencies in a specific installation folder. It uses ExternalProject_Add for most parts (e.g. Boost, SDL, Lua, curl and OpenSSL), add_subdirectory for a few others (pugixml and lz4) and just install(FILES...) for a few header only libs like JSON for Modern C++, Catch2 and spdlog. It should be noted that there are relatively few interdependencies between the projects in there.
Because it is more convenient to update, I keep a few dependencies that I control myself directly in the source tree, either as git externals or just copies of the source files.
I try to keep usage of system dependencies to a minimum so that the resulting binary is more portable to the average gamer who does not want to know about libraries and dependencies and such nonsense. This setup has been has been mostly painless and working for my three platforms Windows, Linux and Mac – at least as long as I did not try to change it significantly.

Since not all my dependencies are available on conan and small iterations are usually more successful, I decided to proceed by changing only a single dependency to conan. For this dependency, it’s a good idea to pick something that does not have many compile-time options and is more or less platform agnostic. So I opted for boost over, e.g. SDL or wxWidgets. Boost was also one of the most painful dependencies to build, if only for the insane amount of files it produces and the time it takes to copy those ten-thousands of files to the install location.

There are currently two popular variants of boost available through conan. The “normal” variant on conan’s main repository/remote “conan-center” and a modular version that splits boost into its component libraries on the bincrafters remote, e.g. Boost.Filesystem. The modular version is more appealing conceptually, and I also had a better time getting it to work in my first tests, so I picked that. I did a quick grep for #include <boost/ through my code for an initial guess which boost libraries I needed to get and created a corresponding conanfile.txt in my project root.

Now conan plays really nice with “single configuration generators” like the new CMake/Ninja support in VS2017 and onward. Basically, just cd into your build dir and call something like conan install -s build_type=Debug -s build_type=x86 whenever you want to update dependencies. More info can be found in the official documentation. The workflow for CLion is essentially the same.

Conan

After the last command, conan will download (or build) the dependencies and generate a file with all the corresponding paths.
To use it, include it from cmake like this:

It will then provide targets for all the requested boost libraries that you can link to like this:

I wanted to make sure that the compiler build using the new boost files and not the old ones. Because I have a generic include into my devenv that was still going to be in my compilers include-paths for all the other dependencies, so I just renamed boost’s header include folder on disc. After my first successful compile I felt confident enough to delete them.

There was one major problem: some of my in-source dependencies had their own claim on using boost via passed CMake variables, Boost_LIBRARY_DIRS and Boost_INCLUDE_DIR. I adapted their CMakeLists.txt to allow for injecting appropriate targets instead. Not the cleanest solution, but it got my builds green again fast.

There’s a still a lot to cover on this: The other platforms had their own quirks and I migrated way more than just this first project. Also, there is still ways to go for a full migration with my game project. But more on that in my next blog post…

NewsWebinars

This webinar will provide an introduction to developing large C/C++ projects using the package modularization and reuse offered by Conan package manager, and the power and convenience of the CLion IDE, using the CMake build system.

It will be demonstrated how to consume existing packages of popular C and C++ libraries like Poco, Boost, OpenSSL and ZLib, easily from the CLion environment. Then, how to create package will be explained, with a special focus on continuous development of packages from your own, evolving source code.

Join us Wednesday, July 11th, 4pm – 5pm GMT (6pm – 7pm CEST, 9am – 10am PDT).

Space is limited.

Clion Conan

About the presenters:

Conan Executable Not Found

Diego Rodriguez-Losada
Diego’s passions are robotics and SW engineering and development. He has developed many years in C and C++ in the Industrial, Robotics and AI fields. Diego was also a University (tenure track) professor and robotics researcher for 8 years, till 2012, when he quit academia to try to build a C/C++ dependency manager and co-founded a startup. Since then he mostly develops in Python. Diego is a conan.io open source C/C++ package manager co-creator and maintainer, now working at JFrog as SW engineer and C/C++ advocate.

Luis Martinez de Bartolome
Luis is a full stack software engineer with more than 13 years of experience. He has spent the last 5 years mitigating the pains of C/C++ development flows & dependency management. Co-founder of Conan and a proudly Frog 🐸, today spends his time developing Conan and its ecosystem, playing ukulele, growing hydroponic lettuces and enjoying his two kids.

Clion Conan Exiles

Please, register now to reserve a seat.

You can also find a project we’ll be using during the webinar on GitHub.