Searched +full:cmake +full:- +full:build (Results 1 – 25 of 259) sorted by relevance
1234567891011
| /Zephyr-latest/doc/develop/west/ |
| D | build-flash-debug.rst | 1 .. _west-build-flash-debug:
6 Zephyr provides several :ref:`west extension commands <west-extensions>` for
8 ``build``, ``flash``, ``debug``, ``debugserver`` and ``attach``.
11 commands, see :ref:`flash-and-debug-support` in the board porting guide.
13 .. Add a per-page contents at the top of the page. This page is nested
21 .. _west-building:
23 Building: ``west build``
26 .. tip:: Run ``west build -h`` for a quick overview.
28 The ``build`` command helps you build Zephyr applications from source. You can
29 use :ref:`west config <west-config-cmd>` to configure its behavior.
[all …]
|
| D | sign.rst | 1 .. _west-sign:
6 The ``west sign`` :ref:`extension <west-extensions>` command can be used to
9 an external, post-processing tool that "stitches" the final components of
10 the image together. Run ``west sign -h`` for command line help.
15 rimage configuration uses an approach that does not rely on Kconfig or CMake
16 but on :ref:`west config<west-config>`, similar to
17 :ref:`west-building-cmake-config`.
20 flash`` invokes ``west build`` which invokes ``cmake`` and ``ninja`` which invokes
27 difficult. Reproducing a lower ``west sign`` command to debug some build-time issue
28 can be very time-consuming: it requires at least enabling and searching verbose
[all …]
|
| D | zephyr-cmds.rst | 1 .. _west-zephyr-ext-cmds:
6 This page documents miscellaneous :ref:`west-zephyr-extensions`.
8 .. _west-boards:
21 specify the display format yourself you can use the ``--format`` (or ``-f``)
24 west boards -f "{arch}:{name}"
28 west boards -h
30 .. _west-completion:
40 - bash
41 - zsh
42 - fish
[all …]
|
| /Zephyr-latest/doc/build/sysbuild/ |
| D | index.rst | 3 Sysbuild (System build)
6 Sysbuild is a higher-level build system that can be used to combine multiple
7 other build systems together. It is a higher-level layer that combines one
8 or more Zephyr build systems and optional additional build systems
9 into a hierarchical build system.
11 For example, you can use sysbuild to build a Zephyr application together
19 Like Zephyr's :ref:`build system <build_overview>`, sysbuild is written in
20 CMake and uses :ref:`Kconfig <kconfig>`.
27 Single-image build
29 build system.
[all …]
|
| /Zephyr-latest/cmake/ |
| D | package_helper.cmake | 1 # SPDX-License-Identifier: Apache-2.0
6 # to the Zephyr CMake package and module structure.
9 # build tool that is executed during CMake configure time without creating a
10 # complete build system.
12 # It does so by loading the Zephyr CMake modules specified with the 'MODULES'
15 # This script executes the given module identical to Zephyr CMake configure time.
17 # '-S <path-to-sample>'
19 # The build directory will default to current working directory but can be
20 # controlled with: '-B <path-to-build>'
22 # For example, if you were invoking CMake for 'hello_world' sample as:
[all …]
|
| /Zephyr-latest/doc/build/snippets/ |
| D | using.rst | 1 .. _using-snippets:
8 See :ref:`built-in-snippets` for a list of snippets that are provided by
11 Snippets have names. You use snippets by giving their names to the build
14 With west build
19 .. code-block:: console
21 west build -S foo app
25 .. code-block:: console
27 west build -S snippet1 -S snippet2 [...] app
29 With cmake
32 If you are running CMake directly instead of using ``west build``, use the
[all …]
|
| D | writing.rst | 13 additional build system settings, like this:
15 .. code-block:: yaml
17 name: snippet-name
18 # ... build system settings go here ...
20 Build system settings go in other keys in the file as described later on in
24 you can combine a snippet-specific devicetree overlay and a ``.conf`` file like
27 .. code-block:: yaml
36 .. code-block:: yaml
47 ``snippet-<name>`` as a namespace prefix when choosing names for node labels,
50 For example, if your snippet is named ``foo-bar``, write your devicetree
[all …]
|
| /Zephyr-latest/modules/trusted-firmware-m/ |
| D | Kconfig.tfm.partitions | 1 # Configuration for the partitions in the TF-M Module
4 # SPDX-License-Identifier: Apache-2.0
15 Setting this option will cause '-DTFM_PARTITION_PROTECTED_STORAGE'
16 to be passed to the TF-M build system. Look at 'config_default.cmake'
17 in the trusted-firmware-m repository for details regarding this
19 options are handled by the build system in the trusted-firmware-m
26 Setting this option will cause '-DTFM_PARTITION_INTERNAL_TRUSTED_STORAGE'
27 to be passed to the TF-M build system. Look at 'config_default.cmake'
28 in the trusted-firmware-m repository for details regarding this
30 options are handled by the build system in the trusted-firmware-m
[all …]
|
| /Zephyr-latest/cmake/modules/ |
| D | zephyr_default.cmake | 1 # SPDX-License-Identifier: Apache-2.0
5 # This CMake module will load all Zephyr CMake modules in correct order for
6 # default Zephyr build system.
9 # See individual CMake module descriptions
13 # The code line below defines the real minimum supported CMake version.
15 # Unfortunately CMake requires the toplevel CMakeLists.txt file to define the
16 # required version, not even invoking it from a CMake module is sufficient.
22 # Different CMake versions can have very subtle differences, for
23 # instance CMake 3.21 links object files in a different order compared
24 # to CMake 3.20; this produces different binaries.
[all …]
|
| D | doc.cmake | 1 # SPDX-License-Identifier: Apache-2.0
5 # This CMake module will load all Zephyr CMake modules required for a
6 # documentation build.
8 # The following CMake modules will be loaded:
9 # - extensions
10 # - python
11 # - west
12 # - root
13 # - zephyr_module
16 # The Zephyr package required for documentation build setup.
|
| /Zephyr-latest/doc/develop/sca/ |
| D | index.rst | 6 Support for static code analysis tools in Zephyr is possible through CMake.
8 The build setting :makevar:`ZEPHYR_SCA_VARIANT` can be used to specify the SCA
12 Use ``-DZEPHYR_SCA_VARIANT=<tool>``, for example ``-DZEPHYR_SCA_VARIANT=sparse``
20 Support for an SCA tool is implemented in a :file:`sca.cmake` file.
21 The :file:`sca.cmake` must be placed under :file:`{SCA_ROOT}/cmake/sca/{tool}/sca.cmake`.
22 Zephyr itself is always added as an :makevar:`SCA_ROOT` but the build system offers the
28 .. code-block:: none
31 └── cmake/
34 └── sca.cmake # CMake code that configures the tool to be used with Zephyr
36 To add ``foo`` under ``/path/to/my_tools/cmake/sca`` create the following structure:
[all …]
|
| /Zephyr-latest/scripts/west_commands/ |
| D | build.py | 3 # SPDX-License-Identifier: Apache-2.0
22 _ARG_SEPARATOR = '--'
30 west build [-h] [-b BOARD[@REV]]] [-d BUILD_DIR]
31 [-S SNIPPET] [--shield SHIELD]
32 [-t TARGET] [-p {auto, always, never}] [-c] [--cmake-only]
33 [-n] [-o BUILD_OPT] [-f]
34 [--sysbuild | --no-sysbuild] [--domain DOMAIN]
35 [--extra-conf FILE.conf]
36 [--extra-dtc-overlay FILE.overlay]
37 [source_dir] -- [cmake_opt [cmake_opt ...]]
[all …]
|
| D | spdx.py | 3 # SPDX-License-Identifier: Apache-2.0
13 This command creates an SPDX 2.2 tag-value bill of materials
14 following the completion of a Zephyr build.
16 Prior to the build, an empty file must be created at
17 BUILDDIR/.cmake/api/v1/query/codemodel-v2 in order to enable
18 the CMake file-based API, which the SPDX command relies upon.
19 This can be done by calling `west spdx --init` prior to
20 calling `west build`."""
35 # doc/guides/west/zephyr-cmds.rst up to date.
36 parser.add_argument('-i', '--init', action="store_true",
[all …]
|
| D | zcmake.py | 3 # SPDX-License-Identifier: Apache-2.0
4 '''Common definitions for building Zephyr applications with CMake.
9 See build.py for the build command itself.
27 '''Name of the default CMake generator.'''
31 '''Run cmake to (re)generate a build system, a script, etc.
33 :param args: arguments to pass to CMake
34 :param cwd: directory to run CMake in, cwd is default
40 :param env: used adjusted environment when running CMake
44 cmake = shutil.which('cmake')
45 if cmake is None and not dry_run:
[all …]
|
| /Zephyr-latest/doc/services/llext/ |
| D | build.rst | 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
15 In some cases, involving the full Zephyr build system may not be feasible or
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
29 extensions, as it requires minimal additions to an application build system.
32 ----------------------
36 source files. Usage is similar to the standard ``add_custom_target`` CMake
[all …]
|
| /Zephyr-latest/doc/develop/toolchains/ |
| D | custom_cmake.rst | 3 Custom CMake Toolchains
6 To use a custom toolchain defined in an external CMake file, :ref:`set these
9 - Set :envvar:`ZEPHYR_TOOLCHAIN_VARIANT` to your toolchain's name
10 - Set ``TOOLCHAIN_ROOT`` to the path to the directory containing your
11 toolchain's CMake configuration files.
13 Zephyr will then include the toolchain cmake files located in the
16 - :file:`cmake/toolchain/<toolchain name>/generic.cmake`: configures the
20 - :file:`cmake/toolchain/<toolchain name>/target.cmake`: configures the
26 See the zephyr files :zephyr_file:`cmake/modules/FindHostTools.cmake` and
27 :zephyr_file:`cmake/modules/FindTargetTools.cmake` for more details on what your
[all …]
|
| /Zephyr-latest/doc/develop/application/ |
| D | index.rst | 10 …- your **application directory**, :file:`<app>`, is something like :file:`<home>/zephyrproject/app`
11 - its **build directory** is :file:`<app>/build`
17 makes it easier to use ``west build`` and other commands with it. (You can
19 <important-build-vars>` is set appropriately, though.)
24 Zephyr's build system is based on `CMake`_.
26 The build system is application-centric, and requires Zephyr-based applications
27 to initiate building the Zephyr source code. The application build controls
28 the configuration and build process of both the application and Zephyr itself,
32 and build system. You also likely have installed various :ref:`modules`
37 application. This directory contains all application-specific files, such as
[all …]
|
| /Zephyr-latest/doc/develop/ |
| D | modules.rst | 7 order to avoid reinventing the wheel and to reuse as much well-established,
8 mature code as possible when it makes sense. In the context of Zephyr's build
10 Zephyr build system, as described in more detail in other sections on
14 modules, an external project is required to have its own life-cycle outside
29 - Debugger integration
30 - Silicon vendor Hardware Abstraction Layers (HALs)
31 - Cryptography libraries
32 - File Systems
33 - Inter-Process Communication (IPC) libraries
36 references to optional :ref:`binary blobs <bin-blobs>`.
[all …]
|
| /Zephyr-latest/doc/services/tfm/ |
| D | build.rst | 3 TF-M Build System
6 When building a valid ``_ns`` board target, TF-M will be built in the
7 background, and linked with the Zephyr non-secure application. No knowledge
8 of TF-M's build system is required in most cases, and the following will
9 build a TF-M and Zephyr image pair, and run it in qemu with no additional
12 .. code-block:: bash
14 … $ west build -p auto -b mps2/an521/cpu0/ns samples/tfm_integration/psa_protected_storage/ -t run
16 The outputs and certain key steps in this build process are described here,
18 deal with signing the secure and non-secure images before deploying them.
20 Images Created by the TF-M Build
[all …]
|
| /Zephyr-latest/doc/build/cmake/ |
| D | index.rst | 1 .. _cmake-details:
3 Build System (CMake)
7 CMake is used to build your application together with the Zephyr kernel. A
8 CMake build is done in two stages. The first stage is called
9 **configuration**. During configuration, the CMakeLists.txt build scripts are
10 executed. After configuration is finished, CMake has an internal model of the
11 Zephyr build, and can generate build scripts that are native to the host
14 CMake supports generating scripts for several build systems, but only Ninja and
16 **build** stage by executing the generated build scripts. These build scripts
17 can recompile the application without involving CMake following
[all …]
|
| /Zephyr-latest/doc/develop/getting_started/ |
| D | installation_linux.rst | 32 .. group-tab:: Ubuntu
34 .. code-block:: console
36 sudo apt-get update
37 sudo apt-get upgrade
39 .. group-tab:: Fedora
41 .. code-block:: console
45 .. group-tab:: Clear Linux
47 .. code-block:: console
51 .. group-tab:: Arch Linux
53 .. code-block:: console
[all …]
|
| /Zephyr-latest/samples/tfm_integration/tfm_ipc/ |
| D | README.rst | 1 .. zephyr:code-sample:: tfm_ipc
2 :name: TF-M IPC
4 Implement communication between the secure and non-secure images using IPC.
9 This is a simple TF-M integration example that can be used with an ARMv8-M
12 It uses **IPC Mode** for communication, where TF-M API calls are made to the
16 Zephyr uses Trusted Firmware (TF-M) Platform Security Architecture (PSA) APIs
18 non-secure configuration.
20 The sample prints test info to the console either as a single-thread or
21 multi-thread application.
23 The sample reboots after 5 seconds to demonstrate rebooting with TF-M.
[all …]
|
| /Zephyr-latest/doc/build/signing/ |
| D | index.rst | 1 .. _build-signing:
6 Binaries can be optionally signed as part of a build automatically using CMake code, there is
8 latter is documented on :ref:`west-sign`.
13 The Zephyr build system has special support for signing binaries for use with the `MCUboot`_
14 bootloader using the `imgtool`_ program provided by its developers. You can both build and sign
19 :zephyr:code-sample:`hello_world` application for chain-loading by MCUboot. Run these commands
22 .. code-block:: console
24 west build -b YOUR_BOARD zephyr/samples/hello_world --sysbuild -d build-hello-signed -- \
25 -DSB_CONFIG_BOOTLOADER_MCUBOOT=y
27 west flash -d build-hello-signed
[all …]
|
| /Zephyr-latest/boards/infineon/cy8cproto_063_ble/doc/ |
| D | index.rst | 6 The PSOC 6 BLE Proto Kit (CY8CPROTO-063-BLE) is a hardware platform that
12 For more information about the PSOC 63 BLE MCU SoC and CY8CPROTO-063-BLE board:
14 - `PSOC 63 BLE MCU SoC Website`_
15 - `PSOC 63 BLE MCU Datasheet`_
16 - `PSOC 63 BLE MCU Architecture Reference Manual`_
17 - `PSOC 63 BLE MCU Register Reference Manual`_
18 - `CY8CPROTO-063-BLE Website`_
19 - `CY8CPROTO-063-BLE User Guide`_
20 - `CY8CPROTO-063-BLE Schematics`_
25 .. zephyr:board-supported-hw::
[all …]
|
| /Zephyr-latest/doc/build/ |
| D | zephyr_cmake_package.rst | 3 Zephyr CMake Package
6 The Zephyr `CMake package`_ is a convenient way to create a Zephyr-based application.
9 The :ref:`zephyr-app-types` section introduces the application types
12 The Zephyr CMake package ensures that CMake can automatically select a Zephyr installation to use f…
13 the application, whether it is a :ref:`Zephyr repository application <zephyr-repo-app>`,
14 a :ref:`Zephyr workspace application <zephyr-workspace-app>`, or a
15 :ref:`Zephyr freestanding application <zephyr-freestanding-app>`.
17 When developing a Zephyr-based application, then a developer simply needs to write
20 To use the Zephyr CMake package it must first be exported to the `CMake user package registry`_.
22 CMake user package registry.
[all …]
|
1234567891011
