Before You Begin.rst 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250
  1. Step 0: Before You Begin
  2. ========================
  3. The CMake tutorial consists of hands-on exercises writing and building a
  4. C++ project; solving progressively more complex build requirements such
  5. as libraries, code generators, tests, and external dependencies. Before we
  6. are ready to even begin the first step of that journey, we need to ensure we
  7. have the correct tools at hand and understand how to use them.
  8. .. note::
  9. The tutorial material assumes the user has a C++20 compiler and toolchain
  10. available, and at least a beginner understanding of the C++ language. It
  11. is impossible to cover here all the possible ways one might acquire these
  12. prerequisites.
  13. This prerequisite step provides recommendations for how to acquire and
  14. run CMake itself in order to carry out the rest of the tutorial. If you're
  15. already familiar with the basics of how to run CMake, you can feel free to move
  16. on to the rest of the tutorial.
  17. Getting the Tutorial Exercises
  18. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  19. .. include:: include/source.rst
  20. |tutorial_source|
  21. Each step of the tutorial has a corresponding subfolder, which serves as the
  22. starting point for that step's exercises.
  23. Getting CMake
  24. ^^^^^^^^^^^^^
  25. The most obvious way to get your hands on CMake is to download it from the
  26. CMake website. `The website's "Download" section <https://cmake.org/download/>`_
  27. contains the latest builds of CMake for all common (and some uncommon) desktop
  28. platforms.
  29. However, it is preferable to acquire CMake via the usual delivery mechanism for
  30. developer tools on your platform. CMake is available in most packaging
  31. repositories, as a Visual Studio component, and can even be installed from the
  32. Python package index. Additionally, CMake is often available as part of the base
  33. image of most CI/CD runners targeting C/C++. You should consult the documentation
  34. for your software build environment to see if CMake is already available.
  35. CMake can also be compiled from source using the instructions described by
  36. ``README.rst``, found in the root of the CMake source tree.
  37. CMake, like any program, needs to be available in ``PATH`` in order to be run
  38. from a shell. You can verify CMake is available by running any CMake command.
  39. .. code-block:: shell
  40. $ cmake --version
  41. cmake version 3.23.5
  42. CMake suite maintained and supported by Kitware (kitware.com/cmake).
  43. .. note::
  44. If using a Visual Studio-provided development environment, it is best to run
  45. CMake from inside a Developer Command Prompt or Developer Powershell. This
  46. ensures CMake has access to all the required developer tooling and
  47. environment variables.
  48. CMake Generators
  49. ^^^^^^^^^^^^^^^^
  50. CMake is a configuration program, sometimes called a "meta" build system. As
  51. with other configuration systems, CMake is not ultimately responsible for
  52. running the commands which produce the software build. Instead, CMake generates
  53. a build system based on project, environment, and user-provided configuration
  54. information.
  55. CMake supports multiple build systems as the output of this configuration
  56. process. These output backends are called "generators", because they generate
  57. the build system. CMake supports many generators, the documentation for
  58. which can be found at :manual:`cmake-generators(7)`. Information about
  59. supported generators for your particular CMake installation can be found
  60. via :option:`cmake --help` under the "Generators" heading.
  61. Using CMake thus requires one of the build programs which consumes this
  62. generator output be available. The ``Unix Makefiles``, ``Ninja``, and
  63. ``Visual Studio`` generators require a compatible ``make``, ``ninja``, and
  64. ``Visual Studio`` installation respectively.
  65. .. note::
  66. The default generator on Windows is typically the newest available Visual
  67. Studio version on the machine running CMake, everywhere else it is
  68. ``Unix Makefiles``.
  69. Which generator is used can be controlled via the :envvar:`CMAKE_GENERATOR`
  70. environment variable, or the :option:`cmake -G` option.
  71. Single and Multi-Configuration Generators
  72. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  73. In many cases, it is possible to treat the underlying build system as an
  74. implementation detail and not differentiate between, for example, ``ninja``
  75. and ``make`` when using CMake. However, there is one significant property
  76. of a given generator which we need to be aware of for even trivial workflows:
  77. if the generator supports single configuration builds, or if it supports
  78. multi-configuration builds.
  79. Software builds often have several variants which we might be interested in.
  80. These variants have names like ``Debug``, ``Release``, ``RelWithDebInfo``, and
  81. ``MinSizeRel``, with properties corresponding to the name of the given variant.
  82. A single-configuration build system always builds the software the same way, if
  83. it is generated to produce ``Debug`` builds it will always produce
  84. a ``Debug`` build. A multi-configuration build system can produce different
  85. outputs depending on the configuration specified at build time.
  86. .. note::
  87. The terms **build configuration** and **build type** are synonymous. When
  88. dealing with single-configuration generators, which only support a single
  89. variant, the generated variant is usually called the "build type".
  90. When dealing with multi-configuration generators, the available variants are
  91. usually called the "build configurations". Selecting a variant at build
  92. time is usually called "selecting a configuration" and referred to by flags
  93. and variables as the "config".
  94. However, this convention is not universal. Both technical and colloquial
  95. documentation often mix the two terms. *Configuration* and *config* are
  96. considered the more correct in contexts which generically address both single
  97. and multi-configuration generators.
  98. The commonly used generators are as follows:
  99. +-----------------------------+---------------------------------+
  100. | Single-Configuration | Multi-Configuration |
  101. +=============================+=================================+
  102. | :generator:`Ninja` | :generator:`Ninja Multi-Config` |
  103. +-----------------------------+---------------------------------+
  104. | :generator:`Unix Makefiles` | Visual Studio (all versions) |
  105. +-----------------------------+---------------------------------+
  106. | :generator:`FASTBuild` | :generator:`Xcode` |
  107. +-----------------------------+---------------------------------+
  108. When using a single-configuration generator, the build type is selected based on
  109. the :envvar:`CMAKE_BUILD_TYPE` environment variable, or can be specified
  110. directly when invoking CMake via ``cmake -DCMAKE_BUILD_TYPE=<config>``.
  111. .. note::
  112. For the purpose of the tutorial, it is generally unnecessary to specify a
  113. build type when working with single-configuration generators. The
  114. platform-specific default behavior will work for all exercises.
  115. When using a multi-configuration generator, the build configuration is specified
  116. at build time using either a build-system specific mechanism, or via the
  117. :option:`cmake --build --config <cmake--build --config>` option.
  118. Other Usage Basics
  119. ^^^^^^^^^^^^^^^^^^
  120. The rest of the tutorial will cover the remaining usage basics in greater depth,
  121. but for the purpose of ensuring we have a working development environment a few
  122. more CMake option flags will be enumerated here.
  123. :option:`cmake -S \<dir\> <cmake -S>`
  124. Specifies the project root directory, where CMake will find the project
  125. to be built. This contains the root ``CMakeLists.txt`` file which will
  126. be discussed in Step 1 of the tutorial.
  127. When unspecified, defaults to the current working directory.
  128. :option:`cmake -B \<dir\> <cmake -B>`
  129. Specifies the build directory, where CMake will output the files for the
  130. generated build system, as well as artifacts of the build itself when
  131. the build system is run.
  132. When unspecified, defaults to the current working directory.
  133. :option:`cmake --build \<dir\> <cmake --build>`
  134. Runs the build system in the specified build directory. This is a generic
  135. command for all generators. For multi-configuration generators, the desired
  136. configuration can be requested via:
  137. ``cmake --build <dir> --config <cfg>``
  138. Try It Out
  139. ^^^^^^^^^^
  140. The ``Help/guide/tutorial/Step0`` directory contains a simple "Hello World"
  141. C++ project. The specifics of how CMake configures this project will be
  142. discussed in Step 1 of the tutorial, we need only concern ourselves with
  143. running the CMake program itself.
  144. As described above, there are many possible ways we could run CMake depending
  145. on which generator we want to use for the build. If we navigate to the
  146. ``Help/guide/tutorial/Step0`` directory and run:
  147. .. code-block:: shell
  148. cmake -B build
  149. CMake will generate a build system for the Step0 project into
  150. ``Help/guide/tutorial/Step0/build`` using the default generator for the
  151. platform. Alternatively we can specify a specific generator, ``Ninja`` for
  152. example, with:
  153. .. code-block:: shell
  154. cmake -G Ninja -B build
  155. The effect is similar, but will use the ``Ninja`` generator instead of the
  156. platform default.
  157. .. note::
  158. We can't reuse the build directory with different generators. It is necessary
  159. to delete the build directory between CMake runs if you want to switch to a
  160. different generator using the same build directory.
  161. How we build and run the project after generating the build system depends on
  162. the kind of generator we're using. If it is a single-configuration generator on
  163. a non-Windows platform, we can simply do:
  164. .. code-block:: shell
  165. cmake --build build
  166. ./build/hello
  167. .. note::
  168. On Windows we might need to specify the file extension depending on which
  169. shell is in use, ie ``./build/hello.exe``
  170. If we're using a multi-configuration generator, we will want to specify the
  171. build configuration. The default configurations are ``Debug``, ``Release``,
  172. ``RelWithDebInfo``, and ``MinRelSize``. The result of the build will be stored
  173. in a configuration-specific subdirectory of the build folder. So for example we
  174. could run:
  175. .. code-block:: shell
  176. cmake --build build --config Debug
  177. ./build/Debug/hello
  178. Getting Help and Additional Resources
  179. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  180. For help from the CMake community, you can reach out on
  181. `the CMake Discourse Forums <https://discourse.cmake.org/>`_.
  182. .. only:: cmakeorg
  183. For professional training related to CMake, please see
  184. `the CMake training landing page <https://www.kitware.com/courses/cmake-training/>`_.
  185. For other professional CMake services,
  186. `please reach out to us using our contact form <https://www.kitware.com/contact/>`_.