Julian Hall | e76ade8 | 2020-11-25 03:07:21 +0100 | [diff] [blame] | 1 | Build Instructions |
| 2 | ================== |
| 3 | All trusted service builds use CMake to create native build files for building and installing service binaries |
| 4 | and other build products. Details about the tools needed for building are specified here: |
| 5 | :ref:`Software Requirements`. |
| 6 | |
| 7 | All top-level build files are located beneath the 'deployments' parent directory under a sub-directory |
| 8 | for each deployment. For more information about the project directory structure, see: |
| 9 | :ref:`Project Structure`. |
| 10 | |
| 11 | Build Flow |
| 12 | ---------- |
| 13 | All deployment builds follow a common flow that results in the creation of executable binaries or libraries |
| 14 | and the installation of files into an output directory. Deploying the contents of the output directory into |
| 15 | the target environment is handled in an environment specific way and is not part of the common build |
| 16 | flow. The build flow conforms to the conventional CMake process where building takes place in to following |
| 17 | two stages: |
| 18 | |
| 19 | 1. Native build files, such as makefiles, are generated from CMake configuration files. |
| 20 | 2. Native build tools, such as make, are used to build and install items, ready for deployment. |
| 21 | |
| 22 | The following activity diagram illustrates the common deployment build flow. The green activity states |
| 23 | lie outside of the common build flow. Environment specific instructions are provided for deploying into |
| 24 | different environments: |
| 25 | |
| 26 | .. uml:: uml/BuildFlow.puml |
| 27 | |
Gyorgy Szing | 34aaf21 | 2022-10-20 07:26:23 +0200 | [diff] [blame] | 28 | Selecting the build type |
| 29 | ------------------------- |
| 30 | The build type selects code optimization and debug information related compiler settings. The build system follows the |
| 31 | standard CMake methodology and uses the `CMAKE_BUILD_TYPE`_ variable. |
| 32 | |
| 33 | The build system uses the following build types: |
| 34 | |
| 35 | .. list-table:: Supported build types |
| 36 | :header-rows: 1 |
| 37 | |
| 38 | * - Build type |
| 39 | - Purpose |
| 40 | - Description |
| 41 | * - Debug |
| 42 | - For debugging purposes. |
| 43 | - Optimization is off, debugging information generation is enabled. |
| 44 | * - MinSizeRel |
| 45 | - Size optimized release build. |
| 46 | - Optimization is configured to prefer small code size, debugging information is not generated. |
| 47 | * - MinSizWithDebInfo |
| 48 | - For debugging size optimized release build. |
| 49 | - Optimization is configured to prefer small code size, debugging information generation is enabled. |
| 50 | * - Release |
| 51 | - Speed optimized release build. |
| 52 | - Optimization is configured to prefer execution speed, debugging information is not generated. |
| 53 | * - RelWithDebugInfo |
| 54 | - For debugging speed optimized release build. |
| 55 | - Optimization is configured to prefer execution speed, debugging information generation is enabled. |
| 56 | |
| 57 | Build type of external components can be configured with command line parameters. Parameter names follow this pattern: |
| 58 | ``-D<upper case component name>_BUILD_TYPE=<value>`` e.g. ``-DNANOPB_BUILD_TYPE=Release``. Supported values are |
| 59 | component specific, please refer to the appropriate cmake file under ``<TS_ROOT>/external/<name>``. |
| 60 | |
Julian Hall | e76ade8 | 2020-11-25 03:07:21 +0100 | [diff] [blame] | 61 | Building and Installing |
| 62 | ----------------------- |
| 63 | When building from a clean environment where no generated build files exist, it is necessary to run |
| 64 | the CMake command, specifying the source directory, the build directory and optionally, the install |
| 65 | directory where build output is installed. |
| 66 | |
| 67 | To illustrate the steps involved, we will build the 'component-test' executable to run in the |
| 68 | 'linux-pc' environment. The built executable is a standalone program that uses the CppUTest |
| 69 | framework to run a set of component level tests on components from within the project. For this |
| 70 | example, it is assumed that we are building under Linux and 'make' is used as the native build tool. |
| 71 | |
| 72 | The described steps may be used for any of the deployments under the top-level *deployments* directory. |
| 73 | |
| 74 | Starting from the project root directory, change directory to the relevant deployment directory:: |
| 75 | |
| 76 | cd deployments/component-test/linux-pc |
| 77 | |
| 78 | Build file generation is performed using the CMake command. If no CMAKE_INSTALL_PREFIX path is |
| 79 | specified, build output will be installed in the default location (*build/install*). To generate |
| 80 | build files that install to the default location, use:: |
| 81 | |
| 82 | cmake -S . -B build |
| 83 | |
| 84 | To generate build files that install to an alternative location, use:: |
| 85 | |
| 86 | cmake -S . -B build -DCMAKE_INSTALL_PREFIX=<install_dir> |
| 87 | |
| 88 | Having successfully generated build files, the native build tool may be run to build and install |
| 89 | files using:: |
| 90 | |
| 91 | cd build |
| 92 | make install |
| 93 | |
| 94 | In the above example, all build output is written to a sub-directory called 'build'. You |
| 95 | are free to choose any location for build output. |
| 96 | |
| 97 | Dependencies on external components and in-tree built objects, such as libraries, |
| 98 | are handled automatically by the build system during the *generating* phase. External components |
| 99 | are fetched from the relevant source repository and built as part of the build context for the |
| 100 | deployment binary being built. This allows deployment specific configuration and compiler options |
| 101 | to be applied to the external component without impacting other builds. Dependencies on in-tree |
| 102 | built libraries are handled in a similar manner. |
| 103 | |
| 104 | For information on running tests, see: |
| 105 | :ref:`Running Tests`. |
| 106 | |
| 107 | For more information on deployments, see: |
| 108 | :ref:`Deployments`. |
| 109 | |
| 110 | Installed build output files |
| 111 | ---------------------------- |
| 112 | On successfully completing the *building* phase of the build flow, a set of build output files are |
| 113 | installed to the directory specified by CMAKE_INSTALL_PREFIX. The set of installed files will |
| 114 | depend on the type of build and the environment in which the files will be deployed. The following |
| 115 | table summarizes what files are installed for different typed of build during the *installing* phase |
| 116 | of the build flow: |
| 117 | |
| 118 | .. list-table:: Example build output files |
| 119 | :header-rows: 1 |
| 120 | |
| 121 | * - Deployment type |
| 122 | - Environment |
| 123 | - Files installed |
| 124 | * - Binary executable |
| 125 | - linux-pc, arm-linux |
| 126 | - | *bin/* - program binary |
| 127 | * - Shared library |
| 128 | - linux-pc, arm-linux |
| 129 | - | *include/* - public header files |
| 130 | | *lib/* - shared library |
| 131 | | *lib/cmake/* - cmake target import file |
| 132 | * - SP image |
| 133 | - opteesp |
| 134 | - | *bin/* - stripped elf file for SP |
| 135 | | *lib/make* - OP-TEE helper makefile |
| 136 | * - SP collection |
| 137 | - opteesp |
| 138 | - | *bin/* - set of stripped elf files |
| 139 | | *lib/make/* - set of OP-TEE helper makefiles |
| 140 | |
| 141 | |
| 142 | Deploying installed files |
| 143 | ------------------------- |
| 144 | Having built and installed build output files to a known directory, further steps may be needed to |
| 145 | deploy the files into the target processing environment. The nature of these steps will be different |
| 146 | for different environments. |
| 147 | |
| 148 | To avoid overly complicating the common Trusted Services build system, details of how installed files |
| 149 | are deployed into the target execution environment are handled separately and may rely on environment |
| 150 | specific tools. |
| 151 | |
| 152 | Some example deployment methods are: |
| 153 | |
| 154 | * A filesystem share exists between a build machine and the target machine. Files installed into the shared directory are |
| 155 | directly accessible by the target. |
| 156 | * Installed files are incorporated into a third-party build process e.g. OP-TEE. |
| 157 | |
Julian Hall | c6268b0 | 2022-03-10 10:31:09 +0000 | [diff] [blame] | 158 | The following guides provide instructions on deploying services and running programs on FVP: |
Julian Hall | e76ade8 | 2020-11-25 03:07:21 +0100 | [diff] [blame] | 159 | |
| 160 | * :ref:`Deploying trusted services in S-EL0 Secure Partitions under OP-TEE` |
Julian Hall | c6268b0 | 2022-03-10 10:31:09 +0000 | [diff] [blame] | 161 | * :ref:`Running User-space Programs on FVP` |
Julian Hall | e76ade8 | 2020-11-25 03:07:21 +0100 | [diff] [blame] | 162 | |
| 163 | Batch Building |
| 164 | -------------- |
| 165 | To support batching building of a set of deployments, a tool called b-test is included. For |
| 166 | more information, see |
| 167 | :doc:`b-test page <./b-test>` |
| 168 | |
| 169 | -------------- |
| 170 | |
Gyorgy Szing | 34aaf21 | 2022-10-20 07:26:23 +0200 | [diff] [blame] | 171 | .. _CMAKE_BUILD_TYPE: https://cmake.org/cmake/help/v3.18/variable/CMAKE_BUILD_TYPE.html |
| 172 | |
| 173 | *Copyright (c) 2020-2022, Arm Limited and Contributors. All rights reserved.* |
Julian Hall | e76ade8 | 2020-11-25 03:07:21 +0100 | [diff] [blame] | 174 | |
| 175 | SPDX-License-Identifier: BSD-3-Clause |