Lines Matching full:the
4 The LLEXT subsystem allows for the creation of extensions that can be loaded
6 often useful to have access to the headers and compiler flags used by the main
9 The easiest path to achieve this is to build the extension as part of the
10 Zephyr application, using the `native Zephyr CMake features
11 <llext_build_native_>`_. This will result in a single build providing both the
12 main Zephyr application and the extension(s), which will all automatically be
13 built with the same parameters.
15 In some cases, involving the full Zephyr build system may not be feasible or
16 convenient; maybe the extension is built using a different compiler suite or as
17 part of a different project altogether. In this case, the extension developer
18 needs to export the headers and compiler flags used by the main Zephyr
19 application. This can be done using the `LLEXT Extension Development Kit
24 Using the Zephyr CMake features
27 The Zephyr build system provides a set of features that can be used to build
28 extensions as part of the Zephyr application. This is the simplest way to build
31 Building the extension
34 An extension can be defined in the app's ``CMakeLists.txt`` by invoking the
35 ``add_llext_target`` function, providing the target name, the output and the
36 source files. Usage is similar to the standard ``add_custom_target`` CMake
49 - ``<target_name>`` is the name of the final CMake target that will result in
50 the LLEXT binary being created;
51 - ``<ext_file.llext>`` is the name of the output file that will contain the
53 - ``<src1> [<src2>...]`` is the list of source files that will be compiled to
54 create the extension.
56 The exact steps of the extension building process depend on the currently
59 The following custom properties of ``<target_name>`` are defined and can be
60 retrieved using the ``get_target_property()`` CMake function:
64 Target name for the source compilation and/or link step.
68 The binary file resulting from compilation and/or linking steps.
72 The file to be used as input for the packaging step.
76 The final extension file name.
78 Tweaking the build process
81 The following CMake functions can be used to modify the build system behavior
82 during the extension build process to a fine degree. Each of the below
83 functions takes the LLEXT target name as its first argument; it is otherwise
84 functionally equivalent to the common Zephyr ``target_*`` version.
95 The ``add_llext_command`` CMake function can be used to add custom build steps
96 that will be executed during the extension build process. The command will be
97 run at the specified build step and can refer to the properties of the target
100 The function signature is:
110 The different build steps are:
114 Before the extension code is linked, if the architecture uses dynamic
119 After the extension code is built, but before packaging it in an ``.llext``
120 file. This step is expected to create a `pkg_input` file by reading the
125 After the extension output file has been created. The command can operate
126 on the final llext file `pkg_output`.
136 When building extensions as a standalone project, outside of the main Zephyr
137 build system, it's important to have access to the same set of generated
138 headers and compiler flags used by the main Zephyr application, since they have
139 a direct impact on how Zephyr headers are interpreted and the extension is
143 (EDK) from the build artifacts of the main Zephyr application, by running the
144 following command which uses the ``llext-edk`` target:
150 The generated EDK can be found in the build directory under the ``zephyr``
151 directory. It's a tarball that contains the headers and compile flags needed
152 to build extensions. The extension developer can then include the headers
153 and use the compile flags in their build system to build the extension.
158 The EDK includes the convenience files ``cmake.cflags`` (for CMake-based
160 variables that contain the compile flags needed by the project. The full list
168 to the compiler's include search paths.
173 the compiler's include search paths.
177 Compiler flags to add all directories containing headers used in the
178 build to the compiler's include search paths. This is a combination of
183 Compiler flags for autogenerated headers that must be included in the
188 Other compiler flags that control code generation for the target CPU.
189 None of these flags are included in the above lists.
202 The LLEXT EDK can be configured using the following Kconfig options:
205 The name of the generated EDK tarball.
208 If set, the EDK will include headers that do not contain code to route
209 syscalls to the kernel. This is useful when building extensions that will
215 Refer to :zephyr:code-sample:`llext-edk` for an example of how to use the