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``) |
| 25 | * Display memory usage report cards (with pw_bloat) |
| 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 | ========== |
| 33 | The common configuration for GN for all modules is in the ``BUILD.gn`` file. |
| 34 | It contains ``config`` declarations referenced by ``BUILD.gn`` files in other |
| 35 | modules. |
| 36 | |
Alexei Frolov | 69ad192 | 2019-12-13 13:11:32 -0800 | [diff] [blame] | 37 | The module also provides some useful GN templates for build targets. |
| 38 | |
| 39 | Templates |
| 40 | --------- |
| 41 | |
| 42 | pw_executable |
| 43 | ^^^^^^^^^^^^^ |
| 44 | .. code:: |
| 45 | |
| 46 | import("$dir_pw_build/pw_executable.gni") |
| 47 | |
| 48 | The ``pw_executable`` template is a wrapper around executable targets which |
| 49 | builds for a globally-defined target type. This is controlled by the build |
| 50 | variable ``pw_executable_config.target_type``. For example, setting this |
| 51 | variable to ``stm32f429i_executable`` causes all executable targets to build |
| 52 | using that template. |
| 53 | |
| 54 | .. tip:: |
| 55 | |
| 56 | Prefer to use ``pw_executable`` over plain ``executable`` targets to allow |
| 57 | cleanly building the same code for multiple target configs. |
| 58 | |
| 59 | **Arguments** |
| 60 | |
| 61 | ``pw_executable`` accepts any arguments, as it simply forwards them through to |
| 62 | the specified custom template. |
| 63 | |
| 64 | pw_python_script |
| 65 | ^^^^^^^^^^^^^^^^ |
| 66 | The ``pw_python_script`` template is a convenience wrapper around ``action`` for |
| 67 | running Python scripts. The main benefit it provides is automatic resolution of |
| 68 | GN paths to filesystem paths and GN target names to compiled binary files. This |
| 69 | allows Python scripts to be written independent of GN, taking only filesystem as |
| 70 | arguments. |
| 71 | |
| 72 | Another convenience provided by the template is to allow running scripts without |
| 73 | any outputs. Sometimes scripts run in a build do not directly produce output |
| 74 | files, but GN requires that all actions have an output. ``pw_python_script`` |
| 75 | solves this by accepting a boolean ``stamp`` argument which tells it to create a |
| 76 | dummy output file for the action. |
| 77 | |
| 78 | **Arguments** |
| 79 | |
| 80 | ``pw_python_script`` accepts all of the arguments of a regular ``action`` |
| 81 | target. Additionally, it has some of its own arguments: |
| 82 | |
| 83 | * ``stamp``: Optional boolean indicating whether to automatically create a dummy |
| 84 | output file for the script. This allows running scripts without specifying any |
| 85 | ``outputs``. |
| 86 | |
| 87 | **Example** |
| 88 | |
| 89 | .. code:: |
| 90 | |
| 91 | import("$dir_pw_build/python_script.gni") |
| 92 | |
| 93 | python_script("hello_world") { |
| 94 | script = "py/say_hello.py" |
| 95 | args = [ "world" ] |
| 96 | stamp = true |
| 97 | } |
| 98 | |
| 99 | pw_input_group |
| 100 | ^^^^^^^^^^^^^^ |
| 101 | ``pw_input_group`` defines a group of input files which are not directly |
| 102 | processed by the build but are still important dependencies of later build |
| 103 | steps. This is commonly used alongside metadata to propagate file dependencies |
| 104 | through the build graph and force rebuilds on file modifications. |
| 105 | |
| 106 | For example ``pw_docgen`` defines a ``pw_doc_group`` template which outputs |
| 107 | metadata from a list of input files. The metadata file is not actually part of |
| 108 | the build, and so changes to any of the input files do not trigger a rebuild. |
| 109 | This is problematic, as targets that depend on the metadata should rebuild when |
| 110 | the inputs are modified but GN cannot express this dependency. |
| 111 | |
| 112 | ``pw_input_group`` solves this problem by allowing a list of files to be listed |
| 113 | in a target that does not output any build artifacts, causing all dependent |
| 114 | targets to correctly rebuild. |
| 115 | |
| 116 | **Arguments** |
| 117 | |
| 118 | ``pw_input_group`` accepts all arguments that can be passed to a ``group`` |
| 119 | target, as well as requiring one extra: |
| 120 | |
| 121 | * ``inputs``: List of input files. |
| 122 | |
| 123 | **Example** |
| 124 | |
| 125 | .. code:: |
| 126 | |
| 127 | import("$dir_pw_build/input_group.gni") |
| 128 | |
| 129 | pw_input_group("foo_metadata") { |
| 130 | metadata = { |
| 131 | files = [ |
| 132 | "x.foo", |
| 133 | "y.foo", |
| 134 | "z.foo", |
| 135 | ] |
| 136 | } |
| 137 | inputs = metadata.files |
| 138 | } |
| 139 | |
| 140 | Targets depending on ``foo_metadata`` will rebuild when any of the ``.foo`` |
| 141 | files are modified. |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 142 | |
Wyatt Hepler | 0fbcdfc | 2020-01-02 07:53:39 -0800 | [diff] [blame] | 143 | CMake / Ninja |
| 144 | ============= |
| 145 | The following command generates Ninja build files in the out/cmake directory. |
| 146 | |
| 147 | .. code:: sh |
| 148 | |
| 149 | cmake -B out/cmake -S /path/to/pigweed -G Ninja |
| 150 | |
| 151 | Tests can be executed with the ``pw_run_tests_GROUP`` targets. To run the basic |
| 152 | Pigweed tests, run ``ninja -C out/cmake pw_run_tests_modules``. |
| 153 | |
| 154 | CMake functions |
| 155 | --------------- |
| 156 | CMake convenience functions are defined in ``pw_build/pigweed.cmake``. |
| 157 | |
| 158 | * ``pw_auto_add_simple_module`` -- For modules with only one library, |
| 159 | automatically declare the library and its tests. |
| 160 | * ``pw_add_facade`` -- Declare a module facade. |
| 161 | * ``pw_add_module_library`` -- Add a library that is part of a module. |
| 162 | * ``pw_add_test`` -- Declare a test target. |
| 163 | |
| 164 | See ``pw_build/pigweed.cmake`` for the complete documentation of these |
| 165 | functions. |
| 166 | |
| 167 | Special libraries that do not fit well with these functions are created with the |
| 168 | standard CMake functions, such as ``add_library`` and ``target_link_libraries``. |
| 169 | |
| 170 | Use Pigweed from an existing CMake project |
| 171 | ------------------------------------------ |
| 172 | To use Pigweed libraries form a CMake-based project, simply include the Pigweed |
| 173 | repository from a ``CMakeLists.txt``. |
| 174 | |
| 175 | .. code:: cmake |
| 176 | |
| 177 | add_subdirectory(path/to/pigweed pigweed) |
| 178 | |
| 179 | All module libraries will be available as ``module_name`` or |
| 180 | ``module_name.sublibrary``. |
| 181 | |
| 182 | If desired, modules can be included individually. |
| 183 | |
| 184 | .. code:: cmake |
| 185 | |
| 186 | include(path/to/pigweed/pw_build/pigweed.cmake) |
| 187 | |
| 188 | add_subdirectory(path/to/pigweed/pw_some_module pw_some_module) |
| 189 | add_subdirectory(path/to/pigweed/pw_another_module pw_another_module) |
| 190 | |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 191 | Bazel |
| 192 | ===== |
| 193 | The common configuration for Bazel for all modules is in the ``pigweed.bzl`` |
| 194 | file. The built-in Bazel rules ``cc_binary``, ``cc_library``, and ``cc_test`` |
| 195 | are wrapped with ``pw_cc_binary``, ``pw_cc_library``, and ``pw_cc_test``. |
| 196 | These wrappers add parameters to calls to the compiler and linker. |
| 197 | |
| 198 | The ``BUILD`` file is merely a placeholder and currently does nothing. |