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 |
| 11 | either `GN`_/`Ninja`_ or `Bazel`_. |
| 12 | |
| 13 | .. _GN: https://gn.googlesource.com/gn/ |
| 14 | .. _Ninja: https://ninja-build.org/ |
| 15 | .. _Bazel: https://bazel.build/ |
| 16 | |
| 17 | GN / Ninja |
| 18 | ========== |
| 19 | The common configuration for GN for all modules is in the ``BUILD.gn`` file. |
| 20 | It contains ``config`` declarations referenced by ``BUILD.gn`` files in other |
| 21 | modules. |
| 22 | |
Alexei Frolov | 69ad192 | 2019-12-13 13:11:32 -0800 | [diff] [blame] | 23 | The module also provides some useful GN templates for build targets. |
| 24 | |
| 25 | Templates |
| 26 | --------- |
| 27 | |
| 28 | pw_executable |
| 29 | ^^^^^^^^^^^^^ |
| 30 | .. code:: |
| 31 | |
| 32 | import("$dir_pw_build/pw_executable.gni") |
| 33 | |
| 34 | The ``pw_executable`` template is a wrapper around executable targets which |
| 35 | builds for a globally-defined target type. This is controlled by the build |
| 36 | variable ``pw_executable_config.target_type``. For example, setting this |
| 37 | variable to ``stm32f429i_executable`` causes all executable targets to build |
| 38 | using that template. |
| 39 | |
| 40 | .. tip:: |
| 41 | |
| 42 | Prefer to use ``pw_executable`` over plain ``executable`` targets to allow |
| 43 | cleanly building the same code for multiple target configs. |
| 44 | |
| 45 | **Arguments** |
| 46 | |
| 47 | ``pw_executable`` accepts any arguments, as it simply forwards them through to |
| 48 | the specified custom template. |
| 49 | |
| 50 | pw_python_script |
| 51 | ^^^^^^^^^^^^^^^^ |
| 52 | The ``pw_python_script`` template is a convenience wrapper around ``action`` for |
| 53 | running Python scripts. The main benefit it provides is automatic resolution of |
| 54 | GN paths to filesystem paths and GN target names to compiled binary files. This |
| 55 | allows Python scripts to be written independent of GN, taking only filesystem as |
| 56 | arguments. |
| 57 | |
| 58 | Another convenience provided by the template is to allow running scripts without |
| 59 | any outputs. Sometimes scripts run in a build do not directly produce output |
| 60 | files, but GN requires that all actions have an output. ``pw_python_script`` |
| 61 | solves this by accepting a boolean ``stamp`` argument which tells it to create a |
| 62 | dummy output file for the action. |
| 63 | |
| 64 | **Arguments** |
| 65 | |
| 66 | ``pw_python_script`` accepts all of the arguments of a regular ``action`` |
| 67 | target. Additionally, it has some of its own arguments: |
| 68 | |
| 69 | * ``stamp``: Optional boolean indicating whether to automatically create a dummy |
| 70 | output file for the script. This allows running scripts without specifying any |
| 71 | ``outputs``. |
| 72 | |
| 73 | **Example** |
| 74 | |
| 75 | .. code:: |
| 76 | |
| 77 | import("$dir_pw_build/python_script.gni") |
| 78 | |
| 79 | python_script("hello_world") { |
| 80 | script = "py/say_hello.py" |
| 81 | args = [ "world" ] |
| 82 | stamp = true |
| 83 | } |
| 84 | |
| 85 | pw_input_group |
| 86 | ^^^^^^^^^^^^^^ |
| 87 | ``pw_input_group`` defines a group of input files which are not directly |
| 88 | processed by the build but are still important dependencies of later build |
| 89 | steps. This is commonly used alongside metadata to propagate file dependencies |
| 90 | through the build graph and force rebuilds on file modifications. |
| 91 | |
| 92 | For example ``pw_docgen`` defines a ``pw_doc_group`` template which outputs |
| 93 | metadata from a list of input files. The metadata file is not actually part of |
| 94 | the build, and so changes to any of the input files do not trigger a rebuild. |
| 95 | This is problematic, as targets that depend on the metadata should rebuild when |
| 96 | the inputs are modified but GN cannot express this dependency. |
| 97 | |
| 98 | ``pw_input_group`` solves this problem by allowing a list of files to be listed |
| 99 | in a target that does not output any build artifacts, causing all dependent |
| 100 | targets to correctly rebuild. |
| 101 | |
| 102 | **Arguments** |
| 103 | |
| 104 | ``pw_input_group`` accepts all arguments that can be passed to a ``group`` |
| 105 | target, as well as requiring one extra: |
| 106 | |
| 107 | * ``inputs``: List of input files. |
| 108 | |
| 109 | **Example** |
| 110 | |
| 111 | .. code:: |
| 112 | |
| 113 | import("$dir_pw_build/input_group.gni") |
| 114 | |
| 115 | pw_input_group("foo_metadata") { |
| 116 | metadata = { |
| 117 | files = [ |
| 118 | "x.foo", |
| 119 | "y.foo", |
| 120 | "z.foo", |
| 121 | ] |
| 122 | } |
| 123 | inputs = metadata.files |
| 124 | } |
| 125 | |
| 126 | Targets depending on ``foo_metadata`` will rebuild when any of the ``.foo`` |
| 127 | files are modified. |
Rob Mohr | 84f234e | 2019-12-06 09:16:50 -0800 | [diff] [blame] | 128 | |
| 129 | Bazel |
| 130 | ===== |
| 131 | The common configuration for Bazel for all modules is in the ``pigweed.bzl`` |
| 132 | file. The built-in Bazel rules ``cc_binary``, ``cc_library``, and ``cc_test`` |
| 133 | are wrapped with ``pw_cc_binary``, ``pw_cc_library``, and ``pw_cc_test``. |
| 134 | These wrappers add parameters to calls to the compiler and linker. |
| 135 | |
| 136 | The ``BUILD`` file is merely a placeholder and currently does nothing. |