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 | |
| 28 | Building and Installing |
| 29 | ----------------------- |
| 30 | When building from a clean environment where no generated build files exist, it is necessary to run |
| 31 | the CMake command, specifying the source directory, the build directory and optionally, the install |
| 32 | directory where build output is installed. |
| 33 | |
| 34 | To illustrate the steps involved, we will build the 'component-test' executable to run in the |
| 35 | 'linux-pc' environment. The built executable is a standalone program that uses the CppUTest |
| 36 | framework to run a set of component level tests on components from within the project. For this |
| 37 | example, it is assumed that we are building under Linux and 'make' is used as the native build tool. |
| 38 | |
| 39 | The described steps may be used for any of the deployments under the top-level *deployments* directory. |
| 40 | |
| 41 | Starting from the project root directory, change directory to the relevant deployment directory:: |
| 42 | |
| 43 | cd deployments/component-test/linux-pc |
| 44 | |
| 45 | Build file generation is performed using the CMake command. If no CMAKE_INSTALL_PREFIX path is |
| 46 | specified, build output will be installed in the default location (*build/install*). To generate |
| 47 | build files that install to the default location, use:: |
| 48 | |
| 49 | cmake -S . -B build |
| 50 | |
| 51 | To generate build files that install to an alternative location, use:: |
| 52 | |
| 53 | cmake -S . -B build -DCMAKE_INSTALL_PREFIX=<install_dir> |
| 54 | |
| 55 | Having successfully generated build files, the native build tool may be run to build and install |
| 56 | files using:: |
| 57 | |
| 58 | cd build |
| 59 | make install |
| 60 | |
| 61 | In the above example, all build output is written to a sub-directory called 'build'. You |
| 62 | are free to choose any location for build output. |
| 63 | |
| 64 | Dependencies on external components and in-tree built objects, such as libraries, |
| 65 | are handled automatically by the build system during the *generating* phase. External components |
| 66 | are fetched from the relevant source repository and built as part of the build context for the |
| 67 | deployment binary being built. This allows deployment specific configuration and compiler options |
| 68 | to be applied to the external component without impacting other builds. Dependencies on in-tree |
| 69 | built libraries are handled in a similar manner. |
| 70 | |
| 71 | For information on running tests, see: |
| 72 | :ref:`Running Tests`. |
| 73 | |
| 74 | For more information on deployments, see: |
| 75 | :ref:`Deployments`. |
| 76 | |
| 77 | Installed build output files |
| 78 | ---------------------------- |
| 79 | On successfully completing the *building* phase of the build flow, a set of build output files are |
| 80 | installed to the directory specified by CMAKE_INSTALL_PREFIX. The set of installed files will |
| 81 | depend on the type of build and the environment in which the files will be deployed. The following |
| 82 | table summarizes what files are installed for different typed of build during the *installing* phase |
| 83 | of the build flow: |
| 84 | |
| 85 | .. list-table:: Example build output files |
| 86 | :header-rows: 1 |
| 87 | |
| 88 | * - Deployment type |
| 89 | - Environment |
| 90 | - Files installed |
| 91 | * - Binary executable |
| 92 | - linux-pc, arm-linux |
| 93 | - | *bin/* - program binary |
| 94 | * - Shared library |
| 95 | - linux-pc, arm-linux |
| 96 | - | *include/* - public header files |
| 97 | | *lib/* - shared library |
| 98 | | *lib/cmake/* - cmake target import file |
| 99 | * - SP image |
| 100 | - opteesp |
| 101 | - | *bin/* - stripped elf file for SP |
| 102 | | *lib/make* - OP-TEE helper makefile |
| 103 | * - SP collection |
| 104 | - opteesp |
| 105 | - | *bin/* - set of stripped elf files |
| 106 | | *lib/make/* - set of OP-TEE helper makefiles |
| 107 | |
| 108 | |
| 109 | Deploying installed files |
| 110 | ------------------------- |
| 111 | Having built and installed build output files to a known directory, further steps may be needed to |
| 112 | deploy the files into the target processing environment. The nature of these steps will be different |
| 113 | for different environments. |
| 114 | |
| 115 | To avoid overly complicating the common Trusted Services build system, details of how installed files |
| 116 | are deployed into the target execution environment are handled separately and may rely on environment |
| 117 | specific tools. |
| 118 | |
| 119 | Some example deployment methods are: |
| 120 | |
| 121 | * A filesystem share exists between a build machine and the target machine. Files installed into the shared directory are |
| 122 | directly accessible by the target. |
| 123 | * Installed files are incorporated into a third-party build process e.g. OP-TEE. |
| 124 | |
| 125 | The following guides provide instructions on deploying to different environments: |
| 126 | |
| 127 | * :ref:`Deploying trusted services in S-EL0 Secure Partitions under OP-TEE` |
| 128 | * :ref:`Deploying Programs on FVP` |
| 129 | |
| 130 | Batch Building |
| 131 | -------------- |
| 132 | To support batching building of a set of deployments, a tool called b-test is included. For |
| 133 | more information, see |
| 134 | :doc:`b-test page <./b-test>` |
| 135 | |
| 136 | -------------- |
| 137 | |
| 138 | *Copyright (c) 2020-2021, Arm Limited and Contributors. All rights reserved.* |
| 139 | |
| 140 | SPDX-License-Identifier: BSD-3-Clause |