File: Before%20You%20Begin.rst

package info (click to toggle)
cmake 4.2.1-1
  • links: PTS, VCS
  • area: main
  • in suites: experimental
  • size: 152,348 kB
  • sloc: ansic: 403,894; cpp: 303,807; sh: 4,097; python: 3,582; yacc: 3,106; lex: 1,279; f90: 538; asm: 471; lisp: 375; cs: 270; java: 266; fortran: 239; objc: 215; perl: 213; xml: 198; makefile: 108; javascript: 83; pascal: 63; tcl: 55; php: 25; ruby: 22
file content (250 lines) | stat: -rw-r--r-- 10,578 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
Step 0: Before You Begin
========================

The CMake tutorial consists of hands-on exercises writing and building a
C++ project; solving progressively more complex build requirements such
as libraries, code generators, tests, and external dependencies. Before we
are ready to even begin the first step of that journey, we need to ensure we
have the correct tools at hand and understand how to use them.

.. note::
  The tutorial material assumes the user has a C++20 compiler and toolchain
  available, and at least a beginner understanding of the C++ language. It
  is impossible to cover here all the possible ways one might acquire these
  prerequisites.

This prerequisite step provides recommendations for how to acquire and
run CMake itself in order to carry out the rest of the tutorial. If you're
already familiar with the basics of how to run CMake, you can feel free to move
on to the rest of the tutorial.

Getting the Tutorial Exercises
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

.. include:: include/source.rst

|tutorial_source|
Each step of the tutorial has a corresponding subfolder, which serves as the
starting point for that step's exercises.

Getting CMake
^^^^^^^^^^^^^

The most obvious way to get your hands on CMake is to download it from the
CMake website. `The website's "Download" section <https://cmake.org/download/>`_
contains the latest builds of CMake for all common (and some uncommon) desktop
platforms.

However, it is preferable to acquire CMake via the usual delivery mechanism for
developer tools on your platform. CMake is available in most packaging
repositories, as a Visual Studio component, and can even be installed from the
Python package index. Additionally, CMake is often available as part of the base
image of most CI/CD runners targeting C/C++. You should consult the documentation
for your software build environment to see if CMake is already available.

CMake can also be compiled from source using the instructions described by
``README.rst``, found in the root of the CMake source tree.

CMake, like any program, needs to be available in ``PATH`` in order to be run
from a shell. You can verify CMake is available by running any CMake command.

.. code-block:: shell

  $ cmake --version
  cmake version 3.23.5

  CMake suite maintained and supported by Kitware (kitware.com/cmake).


.. note::
  If using a Visual Studio-provided development environment, it is best to run
  CMake from inside a Developer Command Prompt or Developer Powershell. This
  ensures CMake has access to all the required developer tooling and
  environment variables.

CMake Generators
^^^^^^^^^^^^^^^^

CMake is a configuration program, sometimes called a "meta" build system. As
with other configuration systems, CMake is not ultimately responsible for
running the commands which produce the software build. Instead, CMake generates
a build system based on project, environment, and user-provided configuration
information.

CMake supports multiple build systems as the output of this configuration
process. These output backends are called "generators", because they generate
the build system. CMake supports many generators, the documentation for
which can be found at :manual:`cmake-generators(7)`. Information about
supported generators for your particular CMake installation can be found
via :option:`cmake --help` under the "Generators" heading.

Using CMake thus requires one of the build programs which consumes this
generator output be available. The ``Unix Makefiles``, ``Ninja``, and
``Visual Studio`` generators require a compatible ``make``, ``ninja``, and
``Visual Studio`` installation respectively.

.. note::
  The default generator on Windows is typically the newest available Visual
  Studio version on the machine running CMake, everywhere else it is
  ``Unix Makefiles``.

Which generator is used can be controlled via the :envvar:`CMAKE_GENERATOR`
environment variable, or the :option:`cmake -G` option.

Single and Multi-Configuration Generators
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In many cases, it is possible to treat the underlying build system as an
implementation detail and not differentiate between, for example, ``ninja``
and ``make`` when using CMake. However, there is one significant property
of a given generator which we need to be aware of for even trivial workflows:
if the generator supports single configuration builds, or if it supports
multi-configuration builds.

Software builds often have several variants which we might be interested in.
These variants have names like ``Debug``, ``Release``, ``RelWithDebInfo``, and
``MinSizeRel``, with properties corresponding to the name of the given variant.

A single-configuration build system always builds the software the same way, if
it is generated to produce ``Debug`` builds it will always produce
a ``Debug`` build. A multi-configuration build system can produce different
outputs depending on the configuration specified at build time.

.. note::
  The terms **build configuration** and **build type** are synonymous. When
  dealing with single-configuration generators, which only support a single
  variant, the generated variant is usually called the "build type".

  When dealing with multi-configuration generators, the available variants are
  usually called the "build configurations". Selecting a variant at build
  time is usually called "selecting a configuration" and referred to by flags
  and variables as the "config".

  However, this convention is not universal. Both technical and colloquial
  documentation often mix the two terms. *Configuration* and *config* are
  considered the more correct in contexts which generically address both single
  and multi-configuration generators.

The commonly used generators are as follows:

+-----------------------------+---------------------------------+
| Single-Configuration        | Multi-Configuration             |
+=============================+=================================+
| :generator:`Ninja`          | :generator:`Ninja Multi-Config` |
+-----------------------------+---------------------------------+
| :generator:`Unix Makefiles` | Visual Studio (all versions)    |
+-----------------------------+---------------------------------+
| :generator:`FASTBuild`      | :generator:`Xcode`              |
+-----------------------------+---------------------------------+

When using a single-configuration generator, the build type is selected based on
the :envvar:`CMAKE_BUILD_TYPE` environment variable, or can be specified
directly when invoking CMake via ``cmake -DCMAKE_BUILD_TYPE=<config>``.

.. note::
  For the purpose of the tutorial, it is generally unnecessary to specify a
  build type when working with single-configuration generators. The
  platform-specific default behavior will work for all exercises.

When using a multi-configuration generator, the build configuration is specified
at build time using either a build-system specific mechanism, or via the
:option:`cmake --build --config <cmake--build --config>` option.

Other Usage Basics
^^^^^^^^^^^^^^^^^^

The rest of the tutorial will cover the remaining usage basics in greater depth,
but for the purpose of ensuring we have a working development environment a few
more CMake option flags will be enumerated here.


  :option:`cmake -S \<dir\> <cmake -S>`
    Specifies the project root directory, where CMake will find the project
    to be built. This contains the root ``CMakeLists.txt`` file which will
    be discussed in Step 1 of the tutorial.

    When unspecified, defaults to the current working directory.

  :option:`cmake -B \<dir\> <cmake -B>`
    Specifies the build directory, where CMake will output the files for the
    generated build system, as well as artifacts of the build itself when
    the build system is run.

    When unspecified, defaults to the current working directory.

  :option:`cmake --build \<dir\> <cmake --build>`
    Runs the build system in the specified build directory. This is a generic
    command for all generators. For multi-configuration generators, the desired
    configuration can be requested via:

    ``cmake --build <dir> --config <cfg>``

Try It Out
^^^^^^^^^^

The ``Help/guide/tutorial/Step0`` directory contains a simple "Hello World"
C++ project. The specifics of how CMake configures this project will be
discussed in Step 1 of the tutorial, we need only concern ourselves with
running the CMake program itself.

As described above, there are many possible ways we could run CMake depending
on which generator we want to use for the build. If we navigate to the
``Help/guide/tutorial/Step0`` directory and run:

.. code-block:: shell

  cmake -B build

CMake will generate a build system for the Step0 project into
``Help/guide/tutorial/Step0/build`` using the default generator for the
platform. Alternatively we can specify a specific generator, ``Ninja`` for
example, with:

.. code-block:: shell

  cmake -G Ninja -B build

The effect is similar, but will use the ``Ninja`` generator instead of the
platform default.

.. note::
  We can't reuse the build directory with different generators. It is necessary
  to delete the build directory between CMake runs if you want to switch to a
  different generator using the same build directory.

How we build and run the project after generating the build system depends on
the kind of generator we're using. If it is a single-configuration generator on
a non-Windows platform, we can simply do:

.. code-block:: shell

  cmake --build build
  ./build/hello

.. note::
  On Windows we might need to specify the file extension depending on which
  shell is in use, ie ``./build/hello.exe``

If we're using a multi-configuration generator, we will want to specify the
build configuration. The default configurations are ``Debug``, ``Release``,
``RelWithDebInfo``, and ``MinRelSize``. The result of the build will be stored
in a configuration-specific subdirectory of the build folder. So for example we
could run:

.. code-block:: shell

  cmake --build build --config Debug
  ./build/Debug/hello

Getting Help and Additional Resources
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For help from the CMake community, you can reach out on
`the CMake Discourse Forums <https://discourse.cmake.org/>`_.

.. only:: cmakeorg

  For professional training related to CMake, please see
  `the CMake training landing page <https://www.kitware.com/courses/cmake-training/>`_.
  For other professional CMake services,
  `please reach out to us using our contact form <https://www.kitware.com/contact/>`_.