You're reading from CMake Best Practices Upgrade your C++ builds with CMake for maximum efficiency and scalability

Product type Paperback

Published in Aug 2024

Publisher Packt

ISBN-13 9781835880647

Length 356 pages

Edition 2nd Edition

Languages

C++

Tools

Cmake

Concepts

Application Development

Authors (2):

Mustafa Kemal Gilor

Dominik Berner

View More author details

Table of Contents (22) Chapters

Preface

1. Part 1 – The Basics

2. Chapter 1: Kickstarting CMake FREE CHAPTER

3. Chapter 2: Accessing CMake in the Best Ways

4. Chapter 3: Creating a CMake Project

5. Part 2 – Practical CMake – Getting Your Hands Dirty with CMake

6. Chapter 4: Packaging, Deploying, and Installing a CMake Project

7. Chapter 5: Integrating Third-Party Libraries and Dependency Management

8. Chapter 6: Automatically Generating Documentation

9. Chapter 7: Seamlessly Integrating Code Quality Tools with CMake

10. Chapter 8: Executing Custom Tasks with CMake

11. Chapter 9: Creating Reproducible Build Environments

12. Chapter 10: Handling Distributed Repositories and Dependencies in a Super-Build

13. Chapter 11: Creating Software for Apple Systems

14. Part 3 – Mastering the Details

15. Chapter 12: Cross-Platform-Compiling Custom Toolchains

16. Chapter 13: Reusing CMake Code

17. Chapter 14: Optimizing and Maintaining CMake Projects

18. Chapter 15: Migrating to CMake

19. Index

Why subscribe?

20. Other Books You May Enjoy

Appendix: Contributing to CMake and Further Reading Material

Ensuring version consistency in a super-build

Version consistency is an important aspect of all software projects. As you should have learned by now, nothing is set in stone in the software world. Software evolves and changes over time. Such changes often need to be acknowledged in advance, either by running a series of tests against the new version or by making changes to the consuming code itself. Ideally, changes in upstream code should not have an effect on reproducing existing builds, until we want them to do so. A project’s x.y version should always be built with the z.q dependency version if the software verification and testing have been done against this combination. The reason for this is that the smallest changes in an upstream dependency may affect the behavior of your software, even though there are no API or ABI changes. Your software will not have well-defined behavior if version consistency is not provided. Thus, having a way to provide version consistency is...