Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 1 | .. default-domain:: cpp |
| 2 | |
| 3 | .. highlight:: sh |
| 4 | |
Alexei Frolov | 9d169d5 | 2020-03-03 17:20:06 -0800 | [diff] [blame] | 5 | .. _chapter-build: |
| 6 | |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 7 | -------- |
| 8 | pw_build |
| 9 | -------- |
Alexei Frolov | 9d169d5 | 2020-03-03 17:20:06 -0800 | [diff] [blame] | 10 | Pigweed's modules aim to be easily integratable into both new and existing |
| 11 | embedded projects. To that goal, the ``pw_build`` module provides support for |
| 12 | multiple build systems. Our personal favorite is `GN`_/`Ninja`_, which is used |
| 13 | by upstream developers for its speed and flexibility. `CMake`_ and `Bazel`_ |
| 14 | build files are also provided by all modules, allowing Pigweed to be added to a |
| 15 | project with minimal effort. |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 16 | |
| 17 | .. _GN: https://gn.googlesource.com/gn/ |
| 18 | .. _Ninja: https://ninja-build.org/ |
Alexei Frolov | 9d169d5 | 2020-03-03 17:20:06 -0800 | [diff] [blame] | 19 | .. _CMake: https://cmake.org/ |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 20 | .. _Bazel: https://bazel.build/ |
| 21 | |
Alexei Frolov | 9d169d5 | 2020-03-03 17:20:06 -0800 | [diff] [blame] | 22 | Beyond just compiling code, Pigweed’s GN build system can also: |
| 23 | |
| 24 | * Generate HTML documentation, via our Sphinx integration (with ``pw_docgen``) |
Armando Montanez | 0054a9b | 2020-03-13 13:06:24 -0700 | [diff] [blame] | 25 | * Display memory usage report cards (with ``pw_bloat``) |
Alexei Frolov | 9d169d5 | 2020-03-03 17:20:06 -0800 | [diff] [blame] | 26 | * Incrementally run unit tests after code changes (with ``pw_target_runner``) |
| 27 | * And more! |
| 28 | |
| 29 | These are only supported in the GN build, so we recommend using it if possible. |
| 30 | |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 31 | GN / Ninja |
| 32 | ========== |
Armando Montanez | bcc194b | 2020-03-10 10:23:18 -0700 | [diff] [blame] | 33 | The GN / Ninja build system is the primary build system used for upstream |
| 34 | Pigweed development, and is the most tested and feature-rich build system |
| 35 | Pigweed offers. |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 36 | |
Armando Montanez | bcc194b | 2020-03-10 10:23:18 -0700 | [diff] [blame] | 37 | This module's ``build.gn`` file contains a number of C/C++ ``config`` |
| 38 | declarations that are used by upstream Pigweed to set some architecture-agnostic |
| 39 | compiler defaults. (See Pigweed's ``//BUILDCONFIG.gn``) |
| 40 | |
Armando Montanez | 0054a9b | 2020-03-13 13:06:24 -0700 | [diff] [blame] | 41 | ``pw_build`` also provides several useful GN templates that are used throughout |
Armando Montanez | bcc194b | 2020-03-10 10:23:18 -0700 | [diff] [blame] | 42 | Pigweed. |
Alexei Frolov | 69ad192 | 2019-12-13 13:11:32 -0800 | [diff] [blame] | 43 | |
| 44 | Templates |
| 45 | --------- |
| 46 | |
Alexei Frolov | edd2f14 | 2020-06-09 19:11:27 -0700 | [diff] [blame^] | 47 | Target types |
| 48 | ^^^^^^^^^^^^ |
Alexei Frolov | 69ad192 | 2019-12-13 13:11:32 -0800 | [diff] [blame] | 49 | .. code:: |
| 50 | |
Alexei Frolov | edd2f14 | 2020-06-09 19:11:27 -0700 | [diff] [blame^] | 51 | import("$dir_pw_build/target_types.gni") |
Alexei Frolov | 69ad192 | 2019-12-13 13:11:32 -0800 | [diff] [blame] | 52 | |
Alexei Frolov | edd2f14 | 2020-06-09 19:11:27 -0700 | [diff] [blame^] | 53 | pw_source_set("my_library") { |
| 54 | sources = [ "lib.cc" ] |
| 55 | } |
| 56 | |
| 57 | Pigweed defines wrappers around the four basic GN binary types ``source_set``, |
| 58 | ``executable``, ``static_library``, and ``shared_library``. These wrappers apply |
| 59 | default arguments to each target as specified in the ``default_configs`` and |
| 60 | ``default_public_deps`` build args. Additionally, they allow defaults to be |
| 61 | removed on a per-target basis using ``remove_configs`` and |
| 62 | ``remove_public_deps`` variables, respectively. |
| 63 | |
| 64 | The ``pw_executable`` template provides additional functionality around building |
| 65 | complete binaries. As Pigweed is a collection of libraries, it does not know how |
| 66 | its final targets are built. ``pw_executable`` solves this by letting each user |
| 67 | of Pigweed specify a global executable template for their target, and have |
| 68 | Pigweed build against it. This is controlled by the build variable |
| 69 | ``pw_executable_config.target_type``, specifying the name of the executable |
| 70 | template for a project. |
Alexei Frolov | 69ad192 | 2019-12-13 13:11:32 -0800 | [diff] [blame] | 71 | |
| 72 | .. tip:: |
| 73 | |
| 74 | Prefer to use ``pw_executable`` over plain ``executable`` targets to allow |
| 75 | cleanly building the same code for multiple target configs. |
| 76 | |
| 77 | **Arguments** |
| 78 | |
Alexei Frolov | edd2f14 | 2020-06-09 19:11:27 -0700 | [diff] [blame^] | 79 | All of the ``pw_*`` target type overrides accept any arguments, as they simply |
| 80 | forward them through to the underlying target. |
Alexei Frolov | 69ad192 | 2019-12-13 13:11:32 -0800 | [diff] [blame] | 81 | |
| 82 | pw_python_script |
| 83 | ^^^^^^^^^^^^^^^^ |
| 84 | The ``pw_python_script`` template is a convenience wrapper around ``action`` for |
| 85 | running Python scripts. The main benefit it provides is automatic resolution of |
| 86 | GN paths to filesystem paths and GN target names to compiled binary files. This |
| 87 | allows Python scripts to be written independent of GN, taking only filesystem as |
| 88 | arguments. |
| 89 | |
| 90 | Another convenience provided by the template is to allow running scripts without |
| 91 | any outputs. Sometimes scripts run in a build do not directly produce output |
| 92 | files, but GN requires that all actions have an output. ``pw_python_script`` |
| 93 | solves this by accepting a boolean ``stamp`` argument which tells it to create a |
| 94 | dummy output file for the action. |
| 95 | |
| 96 | **Arguments** |
| 97 | |
| 98 | ``pw_python_script`` accepts all of the arguments of a regular ``action`` |
| 99 | target. Additionally, it has some of its own arguments: |
| 100 | |
| 101 | * ``stamp``: Optional boolean indicating whether to automatically create a dummy |
| 102 | output file for the script. This allows running scripts without specifying any |
| 103 | ``outputs``. |
| 104 | |
| 105 | **Example** |
| 106 | |
| 107 | .. code:: |
| 108 | |
| 109 | import("$dir_pw_build/python_script.gni") |
| 110 | |
| 111 | python_script("hello_world") { |
| 112 | script = "py/say_hello.py" |
| 113 | args = [ "world" ] |
| 114 | stamp = true |
| 115 | } |
| 116 | |
| 117 | pw_input_group |
| 118 | ^^^^^^^^^^^^^^ |
| 119 | ``pw_input_group`` defines a group of input files which are not directly |
| 120 | processed by the build but are still important dependencies of later build |
| 121 | steps. This is commonly used alongside metadata to propagate file dependencies |
| 122 | through the build graph and force rebuilds on file modifications. |
| 123 | |
| 124 | For example ``pw_docgen`` defines a ``pw_doc_group`` template which outputs |
| 125 | metadata from a list of input files. The metadata file is not actually part of |
| 126 | the build, and so changes to any of the input files do not trigger a rebuild. |
| 127 | This is problematic, as targets that depend on the metadata should rebuild when |
| 128 | the inputs are modified but GN cannot express this dependency. |
| 129 | |
| 130 | ``pw_input_group`` solves this problem by allowing a list of files to be listed |
| 131 | in a target that does not output any build artifacts, causing all dependent |
| 132 | targets to correctly rebuild. |
| 133 | |
| 134 | **Arguments** |
| 135 | |
| 136 | ``pw_input_group`` accepts all arguments that can be passed to a ``group`` |
| 137 | target, as well as requiring one extra: |
| 138 | |
| 139 | * ``inputs``: List of input files. |
| 140 | |
| 141 | **Example** |
| 142 | |
| 143 | .. code:: |
| 144 | |
| 145 | import("$dir_pw_build/input_group.gni") |
| 146 | |
| 147 | pw_input_group("foo_metadata") { |
| 148 | metadata = { |
| 149 | files = [ |
| 150 | "x.foo", |
| 151 | "y.foo", |
| 152 | "z.foo", |
| 153 | ] |
| 154 | } |
| 155 | inputs = metadata.files |
| 156 | } |
| 157 | |
| 158 | Targets depending on ``foo_metadata`` will rebuild when any of the ``.foo`` |
| 159 | files are modified. |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 160 | |
Wyatt Hepler | 0fbcdfc | 2020-01-02 07:53:39 -0800 | [diff] [blame] | 161 | CMake / Ninja |
| 162 | ============= |
Armando Montanez | bcc194b | 2020-03-10 10:23:18 -0700 | [diff] [blame] | 163 | |
| 164 | Pigweed's CMake support is provided primarily for projects that have an existing |
| 165 | CMake build and wish to integrate Pigweed without switching to a new build |
| 166 | system. |
| 167 | |
Wyatt Hepler | 0fbcdfc | 2020-01-02 07:53:39 -0800 | [diff] [blame] | 168 | The following command generates Ninja build files in the out/cmake directory. |
| 169 | |
| 170 | .. code:: sh |
| 171 | |
| 172 | cmake -B out/cmake -S /path/to/pigweed -G Ninja |
| 173 | |
| 174 | Tests can be executed with the ``pw_run_tests_GROUP`` targets. To run the basic |
| 175 | Pigweed tests, run ``ninja -C out/cmake pw_run_tests_modules``. |
| 176 | |
| 177 | CMake functions |
| 178 | --------------- |
| 179 | CMake convenience functions are defined in ``pw_build/pigweed.cmake``. |
| 180 | |
| 181 | * ``pw_auto_add_simple_module`` -- For modules with only one library, |
| 182 | automatically declare the library and its tests. |
| 183 | * ``pw_add_facade`` -- Declare a module facade. |
| 184 | * ``pw_add_module_library`` -- Add a library that is part of a module. |
| 185 | * ``pw_add_test`` -- Declare a test target. |
| 186 | |
| 187 | See ``pw_build/pigweed.cmake`` for the complete documentation of these |
| 188 | functions. |
| 189 | |
| 190 | Special libraries that do not fit well with these functions are created with the |
| 191 | standard CMake functions, such as ``add_library`` and ``target_link_libraries``. |
| 192 | |
| 193 | Use Pigweed from an existing CMake project |
| 194 | ------------------------------------------ |
| 195 | To use Pigweed libraries form a CMake-based project, simply include the Pigweed |
| 196 | repository from a ``CMakeLists.txt``. |
| 197 | |
| 198 | .. code:: cmake |
| 199 | |
| 200 | add_subdirectory(path/to/pigweed pigweed) |
| 201 | |
| 202 | All module libraries will be available as ``module_name`` or |
| 203 | ``module_name.sublibrary``. |
| 204 | |
| 205 | If desired, modules can be included individually. |
| 206 | |
| 207 | .. code:: cmake |
| 208 | |
| 209 | include(path/to/pigweed/pw_build/pigweed.cmake) |
| 210 | |
| 211 | add_subdirectory(path/to/pigweed/pw_some_module pw_some_module) |
| 212 | add_subdirectory(path/to/pigweed/pw_another_module pw_another_module) |
| 213 | |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 214 | Bazel |
| 215 | ===== |
Armando Montanez | bcc194b | 2020-03-10 10:23:18 -0700 | [diff] [blame] | 216 | |
| 217 | Bazel is currently very experimental, and only builds for host. |
| 218 | |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 219 | The common configuration for Bazel for all modules is in the ``pigweed.bzl`` |
| 220 | file. The built-in Bazel rules ``cc_binary``, ``cc_library``, and ``cc_test`` |
| 221 | are wrapped with ``pw_cc_binary``, ``pw_cc_library``, and ``pw_cc_test``. |
| 222 | These wrappers add parameters to calls to the compiler and linker. |
| 223 | |
| 224 | The ``BUILD`` file is merely a placeholder and currently does nothing. |