| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250 |
- 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/>`_.
|