Professional CMake实践指南

5星 · 超过95%的资源需积分: 0 99 浏览量更新于2024-06-16 1 收藏 5.72MB PDF 举报

"Professional CMake: A Practical Guide" 《Professional CMake》是一本深入介绍CMake构建系统的实践指南，由Craig Scott撰写。这本书涵盖了CMake的基础到高级应用，旨在帮助开发者更有效地管理和构建C++项目。第14版的ISBN号为978-1-925904-22-2，出版于2018年至2023年。 CMake是一个跨平台的开源构建系统，它允许开发人员用一种统一的方式管理项目在不同操作系统和编译器上的构建过程。CMake通过生成针对特定构建工具（如Make、Visual Studio或Xcode）的项目文件，简化了构建流程的复杂性。书中首先介绍了CMake的基本概念。在“Introduction”章节，作者会阐述CMake的重要性以及它如何解决传统构建方法中的问题。接下来，“Setting Up A Project”部分详细讲解了项目配置的各个方面，包括： - In-source builds：在源代码目录下进行构建，这可能会导致源代码污染，不推荐用于大型项目。 - Out-of-source builds：在源代码外部创建构建目录，保持源代码的干净，是推荐的最佳实践。 - Generating Project Files：使用CMakeLists.txt文件来生成适用于各种IDE和构建工具的项目文件。 - Running The Build Tool：如何执行构建命令，如cmake和make。 - Recommended Practices：作者提供了关于如何高效且整洁地组织CMake项目的建议。 “3. A Minimal Project”章节则演示了一个基本的CMake项目结构，包括如何设置最小的CMakeLists.txt文件，以便成功构建一个简单的C++项目。此外，这本书还可能涉及更高级的主题，如CMake变量、函数、模块、目标（targets）、测试、包管理、跨平台支持等。作者也明确表示，代码示例可以自由使用，无需特别的归因，但书中的策略和建议可能并不适用于所有情况，读者应根据自己的项目需求进行调整。通过阅读本书，读者将能够理解CMake的工作原理，掌握如何编写高效的CMakeLists.txt文件，以及如何构建和管理复杂的C++项目。作者不承担由于书中建议导致的结果责任，鼓励读者在实践中探索和适应最适合自己的构建策略。书末的目录预示着还有更多深入的内容等待读者去发掘，如更多构建技巧、最佳实践以及可能遇到的问题解决方案。

contributors throughout the review process for the first publication. I am truly grateful for their

suggestions and insights. Thanks also to Nils Gladitz for his input, especially at such short notice

before the first publication. I’d also like to thank my past colleagues, Matt Bolger and Lachlan

Hetherton, both of whom provided constructive feedback and reminded me of the importance of a

fresh set of eyes.

A number of people have generously reviewed chapters for subsequent editions. Many of these

people are also CMake contributors or maintainers, and I am grateful for both their time reviewing

this book and in improving CMake itself. Thanks to Cristian Adam for reviewing Chapter 35, Build

Performance and Chapter 36, Working With Qt, and to Tobias Hunger, Alexandru Croitor, Joerg

Bornemann, Sebastian Holtermann and Burkhard Stubert, all of whom also reviewed the material

on Qt at various stages. Alex Turbov provided valuable comments and suggestions for new and

updated material in the 7th edition. Marc Chevrier was kind enough to review material for the 7th

and 13th editions. Adriaan de Groot, Nagy-Egri Máté Ferenc, Michael Platings and Luis Caro

Campos all provided feedback on the 13th edition at short notice, for which I am very thankful.

The helpful feedback received from readers is also much appreciated. I’d like to make particular

mention of the efforts of Declan Moran and Ganesh A. Hegde, both of whom highlighted a number

of improvements and corrections.

A special mention is deserved for my past colleague Mike Wake. Much of the material in this book

was thrashed out and tested in real, actively developed production projects. There have been

wrong turns and many technical discussions on how to improve things from both a usability and

robustness perspective. His support in giving the space and encouragement to work through these

things and his willingness to wear some short-term (and sometimes not-so-short-term) pain have

been an instrumental part of distilling many processes and techniques down to what works in

practice. I am also very grateful for the timely words of advice and encouragement delivered at just

the right time during some of the more stressful and exhausting periods around the earlier

editions.

I would also like to express my gratitude to the people behind Asciidoctor, the software used to

compile and prepare this book. Despite the size, complexity and technical nature of the material, I

have been constantly amazed at how it has made self-publishing not just a viable option, but also

an enjoyable experience with surprisingly few practical limitations. The path from author to reader

is now so much shorter and simpler than when I initially began work on this book. Thanks for the

awesome tool!

The book’s cover and some supporting material on the website are the result of a better eye and

understanding of graphical design than my own. To my friend and designer, V, the way you

somehow managed to make sense of my random, disconnected ideas and conflicting snippets still

baffles me. I don’t understand how you do it, but I do like the end result!

In every book’s acknowledgments section, the author invariably thanks family members and

spouses, and there’s good reason for that. It takes a huge amount of understanding and sacrifice to

tolerate your tiredness, your unavailability to do many of the things ordinary people get to do and

your unreasonable decision to devote more time to a project than to them. I truly cannot express

the depth of my gratitude to my wife for the way she has managed to be so supportive and patient

throughout the process of getting this book written, published and regularly updated. I am indeed a

very fortunate human being.

Chapter 1. Introduction

Whether a seasoned developer or just starting out in a software career, one cannot avoid the

process of becoming familiar with a range of tools in order to turn a project’s source code into

something an end user can actually use. Compilers, linkers, testing frameworks, packaging systems

and more all contribute to the complexity of deploying high quality, robust software. While some

platforms have a dominant IDE environment that simplifies some aspects of this (e.g. Xcode and

Visual Studio), projects that need to support multiple platforms cannot always make use of their

features. Having to support multiple platforms adds more complications that can affect everything

from the set of available tools through to the different capabilities available and restrictions

enforced. A typical developer could be forgiven for losing at least some of their sanity trying to keep

on top of the whole picture.

Fortunately, there are tools that make taming the process more manageable. CMake is one such

tool, or more accurately, CMake is a suite of tools which covers everything from setting up a build

right through to producing packages ready for distribution. Not only does it cover the process from

start to end, it also supports a wide range of platforms, tools and languages. When working with

CMake, it helps to understand its view of the world. Loosely speaking, the start to end process

according to CMake looks something like this:

CMake CTest CPack

Project File Generation

Build Test Package

Configure Generate

The first stage takes a generic project description and generates platform-specific project files

suitable for use with the developer’s regular build tool of choice (e.g. make, Xcode, Visual Studio,

etc.). While this setup stage is what CMake is best known for, the CMake suite of tools also includes

CTest and CPack for managing the later testing and packaging stages respectively. The entire

process from start to finish can be driven from CMake itself, with the testing and packaging steps

available simply as additional targets in the build. Even the build tool can be invoked by CMake.

Before jumping in and getting their hands dirty with CMake, developers will first need to ensure

CMake is installed on their system. Some platforms may typically come with CMake already

installed (eg most Linux distributions have CMake available through their package manager), but

these versions are often quite old. Where possible, it is recommended that developers work with a

recent CMake release. This is particularly true when developing for Apple platforms where tools

like Xcode and its SDKs change rapidly and where app store requirements evolve over time. The

official CMake packages can be downloaded and unpacked to a directory on the developer’s

machine without interfering with any system-wide CMake install. Developers are encouraged to

take advantage of this and remain relatively close to the most recent stable CMake release.

Chapter 2. Setting Up A Project

Without a build system, a project is just a collection of files. CMake brings some order to this,

starting with a human-readable file called CMakeLists.txt that defines what should be built and how,

what tests to run and what package(s) to create. This file is a platform-independent description of

the whole project, which CMake then turns into platform specific build tool project files. As its

name suggests, it is just an ordinary text file which developers edit in their favorite text editor or

development environment. The contents of this file are covered in great detail in subsequent

chapters, but for now, it is enough to know that this is what controls everything that CMake will do

in setting up and performing the build.

A fundamental part of CMake is the concept of a project having both a source directory and a

binary directory. The source directory is where the CMakeLists.txt file is located and the project’s

source files and all other files needed for the build are organized under that location. The source

directory is frequently under version control with a tool like git, subversion, or similar.

The binary directory is where everything produced by the build is created. It is often also called the

build directory. For reasons that will become clear in later chapters, CMake generally uses the term

binary directory, but among developers, the term build directory tends to be in more common use.

This book tends to prefer the latter term since it is generally more intuitive. CMake, the chosen

build tool (e.g. make, Visual Studio, etc.), CTest and CPack will all create various files within the build

directory and subdirectories below it. Executables, libraries, test output and packages are all

created within the build directory. CMake also creates a special file called CMakeCache.txt in the build

directory to store various information for reuse on subsequent runs. Developers won’t normally

need to concern themselves with the CMakeCache.txt file, but later chapters will discuss situations

where this file is relevant. The build tool’s project files (e.g. Xcode or Visual Studio project files,

Makefiles, etc.) are also created in the build directory and are not intended to be put under version

control. The CMakeLists.txt files are the canonical description of the project and the generated

project files should be considered part of the build output.

When a developer commences work on a project, they must decide where they want their build

directory to be in relation to their source directory. There are essentially two approaches: in-source

and out-of-source builds.

2.1. In-source Builds

It is possible, though discouraged, for the source and build directories to be the same. This

arrangement is called an in-source build. Developers at the beginning of their career often start out

using this approach because of the perceived simplicity. The main difficulty with in-source builds,

however, is that all the build outputs are intermixed with the source files. This lack of separation

causes directories to become cluttered with all sorts of files and subdirectories, making it harder to

manage the project sources and running the risk of build outputs overwriting source files. It also

makes working with version control systems more difficult, since there are lots of files created by

the build which either the source control tool has to know to ignore or the developer has to

manually exclude during commits. One other drawback to in-source builds is that it can be non-

trivial to clear out all build output and start again with a clean source tree. For these reasons,

developers are discouraged from using in-source builds where possible, even for simple projects.

剩余663页未读，继续阅读

qq_37328016

粉丝: 0
资源: 1

Professional CMake实践指南

Professional CMake_ A Practical Guide

Professional CMake_ A Practical Guide1.03 .pdf

professional cmake a practical guide

professional cmake pdf

CMake pdf文档

mastering cmake - 高清完整带书签 Cmake PDF 权威学习CMake参考手册

CMake.pdf

CMake实践PDF

2001 CMake实践pdf.pdf

InstallCMake.pdf

最新资源