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