Skip to content

Tools

  • in Tools
  • 16 min read

Introduction to Conan package manager

In the previous article of this series, I have listed several problems that we as developers have to deal with while using dependencies to external code in our projects. These vary from version management, through cross-compilation issues, up to the horror of integration with our build system. Linux users are used to the comfort of working with package managers, which download and install applications and libraries in our host system with simple to use command-line utilities. It would be very handy to have a tool, that does something similar for libraries in the C++ world. Among many previously mentioned package managers, one has stolen my heart and attention for good – Conan.

  • in Tools
  • 10 min read

Problems with external dependencies in C++

Dependencies are usually the most problematic part of the build system (next to the toolchain setup) in programming projects. In C++ this is especially hard because there is no one standard build system. Many more problems arise if we target an embedded system. Other programming languages resolve this issue by having one built-in package manager (usually accompanied by an integrated build system). In C++ we lack both of them, so our lives are much harder. Fortunately, there are a few third-party package managers which get more and more popular. In this series of posts, I will try to convince you to start using one of them – Conan.

  • in Tools
  • 7 min read

How to cross-compile for embedded with CMake like a champ

The power of CMake lies in the fact, that it is both cross-platform in terms of build host and allows cross-compilation for different targets at the same time. In other words, we can build projects from any platform to any platform as long as we have proper tools (usually called toolchains). However many people don’t know about this and try to come up with a sophisticated handmade solution or put complex logic into CMakeLists.txt files in order to setup the environment. Today I’m going to show you how to enable cross-compilation for your project with CMake, basing on the embedded platform case.

  • in Tools
  • 8 min read

How to join repositories in CMake

Sometimes there is a need in a project to use directly some other repository (local or external). This means, that we want to be able to incorporate parts (or all) of sources of the imported repository into our build system. Usually, in such a case we would also like to track which version is used at a given time.

We can solve this problem in a few ways, e.g. by using:

  • git submodules,
  • git subtree,
  • CMake FetchContent,
  • CMake ExternalProject.

First two are handled by the version control system and the last two are handled by the build system. Each of them has its own strengths and weaknesses, depending on the current project needs.

Today I want to briefly present how CMake allows joining repositories with its FetchContent and ExternalProject modules.

  • in Tools
  • 8 min read

Modern CMake is like inheritance

CMake has been created in 2000 by Bill Hoffman from Kitware. During the last 20 years, as of the time of this publication, it’s been constantly evolving by adding new features and expanding its support for third-party libraries. But the most significant additions were released in version 3.0 and are commonly called “Modern CMake”. Despite being available for more than 5 years, many programmers are still not using them!

Today I will show you one of the greatest “Modern CMake” feature, that behaves almost like C++ inheritance. But before we get there, let me briefly explain a few fundaments.

  • in Tools
  • 12 min read

19 reasons why CMake is actually awesome

Topic of CMake is extremely controversial in the C/C++ community. People say that it is hard to properly set the include paths, that syntax is archaic or that managing dependencies is a nightmare. Expressing public hate for CMake has become a way of integrating with other software developers on the Internet.

And I partially understand that statements. Before CMake 3.x (aka Modern CMake) we were forced to use include_directories() or manually set installation paths for libraries, that were not supported by default in CMake. Syntax was a bit oldish and managing the compilation flags usually lead to headaches.

But since CMake 3.x (released on 06.2014) we have way more flexible and elegant ways of creating build systems with CMake. Almost all cons are gone in favor of the new modern solutions. The only problem is that once a bad impression was made, it is really hard to change it. After all, who would like to invest in studying new features and best practices of a build system?! Well I do, and let me share with you 19 reasons, why CMake is actually awesome and you should give it a try again.