Book Image

Modern CMake for C++

By : Rafał Świdziński
5 (2)
Book Image

Modern CMake for C++

5 (2)
By: Rafał Świdziński

Overview of this book

Creating top-notch software is an extremely difficult undertaking. Developers researching the subject have difficulty determining which advice is up to date and which approaches have already been replaced by easier, better practices. At the same time, most online resources offer limited explanation, while also lacking the proper context and structure. This book offers a simpler, more comprehensive, experience as it treats the subject of building C++ solutions holistically. Modern CMake for C++ is an end-to-end guide to the automatization of complex tasks, including building, testing, and packaging. You'll not only learn how to use the CMake language in CMake projects, but also discover what makes them maintainable, elegant, and clean. The book also focuses on the structure of source directories, building targets, and packages. As you progress, you’ll learn how to compile and link executables and libraries, how those processes work, and how to optimize builds in CMake for the best results. You'll understand how to use external dependencies in your project – third-party libraries, testing frameworks, program analysis tools, and documentation generators. Finally, you'll get to grips with exporting, installing, and packaging for internal and external purposes. By the end of this book, you’ll be able to use CMake confidently on a professional level.
Table of Contents (18 chapters)
1
Section 1: Introducing CMake
5
Section 2: Building With CMake
10
Section 3: Automating With CMake

Exporting without installation

How can we make the targets of project A available to the consuming project B? Usually, we'd reach for the find_package() command, but that would mean that we'd need to create a package and install it on the system. That approach is useful, but it takes some work. Sometimes, we just need a really quick way to build a project and make its targets available for other projects.

We could save some time by including the main listfile of A: it contains all the target definitions already. Unfortunately, it also potentially contains a lot of other things: global configuration, requirements, CMake commands with side effects, additional dependencies, and perhaps targets that we don't want in B (such as unit tests). So, let's not do that. It's better to achieve this by providing a target export file that the consuming project, B, can include with the include() command:

cmake_minimum_required(VERSION 3.20.0)
project(B)
include(/path...