OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/cmake/modules/FindTargetTools.cmake

112 lines
4.4 KiB
CMake
Raw Normal View History

license: cleanup: add SPDX Apache-2.0 license identifier Update the files which contain no license information with the 'Apache-2.0' SPDX license identifier. Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of Zephyr, which is Apache version 2. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-04-06 21:08:09 +08:00
# SPDX-License-Identifier: Apache-2.0
cmake: rework of target toolchain handling Follow-up: #41301 This commit is a rework and cleanup of the target toolchain handling in Zephyr CMake build system. Instead of directly loading code a CMake modules for target toolchain lookup, the target toolchain now follows the CMake `find_package()` pattern for finding the target toolchain. This makes it more clear which modules are responsible for finding tools and which modules provides build integration / features. The following tools can now be found using `find_package()`: - Target toolchain: find_package(TargetTools) Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2022-08-30 17:11:36 +08:00
# FindTargetTools module for locating a set of tools to use on the host but
# targeting a remote target for Zephyr development.
#
# This module will lookup following target tools for Zephyr development:
# +---------------------------------------------------------------+
# | Tool | Required | Notes: |
# +---------------------------------------------------------------+
# | Target C-compiler | Yes | |
# | Target Assembler | Yes | |
# | Target linker | Yes | |
# +---------------------------------------------------------------+
#
# The module defines the following variables:
#
# 'CMAKE_C_COMPILER'
# Path to target C compiler.
# Set to 'CMAKE_C_COMPILER-NOTFOUND' if no C compiler was found.
#
# 'TargetTools_FOUND', 'TARGETTOOLS_FOUND'
# True if all required host tools were found.
find_package(HostTools)
if(TargetTools_FOUND)
return()
endif()
cmake: Zephyr CMake package and CMake modules Create a cmake/modules folder containing all Zephyr CMake modules. All Zephyr cmake files that are included from boilerplate are now converted into CMake modules which can be individually loaded. The Zephyr CMake package is updated to support loading of individual CMake modules using the COMPONENTS argument to `find_package(Zephyr)`. If the COMPONENTS argument is not specified, the default Zephyr build system will load. If COMPONENTS is specified then, only those components and the dependencies will be loaded. If a Zephyr CMake module depends on another CMake module which has not been loaded, it will automatically be loaded. This allows us to modularize and reuse individual parts of the Zephyr CMake build system in a more flexible way in future. Such usage could be: - Higher livel multi image build system - Invocation of individual components, for example dts processing by twister without loading all build code - Doc build - Unittesting With this new CMake package and CMake module scheme then direct sourcing of boilerplate.cmake has been deprecated. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-12-17 00:13:54 +08:00
cmake: move CMAKE_<lang>_COMPILER_FORCED into toolchain code. To prepare for more modular approach move the compiler forced out of boilerplate and into the specific toolchain cmake code (generic/target). Code is added to both generic and target toolchain modules to allow future use of one module without requiring a load of the other module. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-12-16 17:05:20 +08:00
# Prevent CMake from testing the toolchain
set(CMAKE_C_COMPILER_FORCED 1)
set(CMAKE_CXX_COMPILER_FORCED 1)
cmake: conditionally enable shared library support When CONFIG_LLEXT is enabled, the Zephyr platform needs to enable dynamic library support. This is done by setting the `TARGET_SUPPORTS_SHARED_LIBS` property to `TRUE` in the global property scope. Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
2024-03-18 23:01:51 +08:00
# https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_NAME.html:
# The name of the operating system for which CMake is to build.
cmake: Document CMAKE_SYSTEM_-variables, and add CMAKE_SYSTEM_VERSION Aid user in understanding what CMake expects of: * Document and add CMAKE_SYSTEM_VERSION * Document CMAKE_SYSTEM_NAME * Document CMAKE_SYSTEM_PROCESSOR * Document BUILD_SHARED_LIBS * Document Policies CMP0002, CMP0079 CMAKE_SYSTEM_VERSION is required officially by CMake, but appears unused -- at least now we are compliant. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 23:01:05 +08:00
#
# https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling:
# CMAKE_SYSTEM_NAME : this one is mandatory, it is the name of the target
# system, i.e. the same as CMAKE_SYSTEM_NAME would have if CMake would run
# on the target system. Typical examples are "Linux" and "Windows". This
# variable is used for constructing the file names of the platform files
# like Linux.cmake or Windows-gcc.cmake. If your target is an embedded
# system without OS set CMAKE_SYSTEM_NAME to "Generic".
cmake: Revert breaking change to CMAKE_SYSTEM_NAME This commit reverts a breaking change in CMAKE_SYSTEM_NAME introduced by "Zephyr" back to "Generic") and removes the file `cmake/modules/Platform/Zephyr`. Both changes in the aforementioned PR were only introduced to ultimately modify the value of the global CMake property TARGET_SUPPORTS_SHARED_LIBS for the special case of building for Xtensa with LLEXT. The modification of CMAKE_SYSTEM_NAME is considered a breaking change because it has the potential to alter the build of any non-trivial project that previously checked for the "Generic" system identifier as corresponding to Zephyr - for example by doing `if (CMAKE_SYSTEM_NAME STREQUAL "Generic")`. Such builds may now break in many ways including silently when there is no `else()` clause with a `message()` to alert the user that a whole configuration block had been skipped. In essence, that CMAKE_SYSTEM_NAME modification was only introduced in order to have CMake to load `cmake/modules/Platform/Zephyr.cmake` which in turn adjusted the value of TARGET_SUPPORTS_SHARED_LIBS. But the use of a CMake platform file like this is ineffective for non-trivial projects where one or more top level CMake `project()` calls may happen before the first call to `find_package(Zephyr)` because in such cases CMAKE_MODULE_PATH will not have been modified yet to contain the path to <Zephyr_ROOT>/cmake/modules and thus no platform file will be include by CMake. This patch moves the conditional override of TARGET_SUPPORTS_SHARED_LIBS needed by some archs (e.g. Xtensa) into the `kernel.cmake` module which is known to be the first call to `project()` that enables any language and thus the one that must come before any artifact target can be defined. Note commit 64e7d85 added a Kconfig to specify the object type of llext being built, so it's not tied to the arch anymore but to the CONFIG_LLEXT_TYPE_ELF_SHAREDLIB option. Signed-off-by: Nicolas Lebedenco <nicolas@lebedenco.net>
2024-04-25 20:47:10 +08:00
set(CMAKE_SYSTEM_NAME Generic)
cmake: Document CMAKE_SYSTEM_-variables, and add CMAKE_SYSTEM_VERSION Aid user in understanding what CMake expects of: * Document and add CMAKE_SYSTEM_VERSION * Document CMAKE_SYSTEM_NAME * Document CMAKE_SYSTEM_PROCESSOR * Document BUILD_SHARED_LIBS * Document Policies CMP0002, CMP0079 CMAKE_SYSTEM_VERSION is required officially by CMake, but appears unused -- at least now we are compliant. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 23:01:05 +08:00
# https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PROCESSOR.html:
# The name of the CPU CMake is building for.
#
# https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling:
# CMAKE_SYSTEM_PROCESSOR : optional, processor (or hardware) of the
# target system. This variable is not used very much except for one
# purpose, it is used to load a
# CMAKE_SYSTEM_NAME-compiler-CMAKE_SYSTEM_PROCESSOR.cmake file,
# which can be used to modify settings like compiler flags etc. for
# the target
cmake: Split toolchain configuration into pre-and post-DT Split up the toolchain configuration into two phases, generic and target. The 'generic' phase configures the toolchain just enough to be able to preprocess DT files. The 'target' phase completes the configuration with target-specific configuration. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-12-13 23:32:07 +08:00
set(CMAKE_SYSTEM_PROCESSOR ${ARCH})
cmake: Document CMAKE_SYSTEM_-variables, and add CMAKE_SYSTEM_VERSION Aid user in understanding what CMake expects of: * Document and add CMAKE_SYSTEM_VERSION * Document CMAKE_SYSTEM_NAME * Document CMAKE_SYSTEM_PROCESSOR * Document BUILD_SHARED_LIBS * Document Policies CMP0002, CMP0079 CMAKE_SYSTEM_VERSION is required officially by CMake, but appears unused -- at least now we are compliant. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 23:01:05 +08:00
# https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_VERSION.html:
# When the CMAKE_SYSTEM_NAME variable is set explicitly to enable cross
# compiling then the value of CMAKE_SYSTEM_VERSION must also be set
# explicitly to specify the target system version.
set(CMAKE_SYSTEM_VERSION ${PROJECT_VERSION})
cmake: propagate endianess to CMake CMAKE_<lang>_BYTE_ORDER setting Fixes: #45270 Zephyr Kconfig defines the settings BIG_ENDIAN. Propagate this setting to the corresponding CMAKE_C_BYTE_ORDER and CMAKE_CXX_BYTE_ORDER variables. This also ensures that the CMake function 'is_big_endian()' reports the correct endianess. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2022-09-26 20:09:39 +08:00
# https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_BYTE_ORDER.html
# Byte order of <LANG> compiler target architecture, if known.
#
# Zephyr Kconfig defines BIG_ENDIAN according to arch, SoC, Board, so propagate
# this setting to allow users to read the standard CMake variable or use
# 'test_big_endian()' function.
if(CONFIG_BIG_ENDIAN)
set(CMAKE_C_BYTE_ORDER BIG_ENDIAN)
set(CMAKE_CXX_BYTE_ORDER BIG_ENDIAN)
else()
set(CMAKE_C_BYTE_ORDER LITTLE_ENDIAN)
set(CMAKE_CXX_BYTE_ORDER LITTLE_ENDIAN)
endif()
cmake: conditionally enable shared library support When CONFIG_LLEXT is enabled, the Zephyr platform needs to enable dynamic library support. This is done by setting the `TARGET_SUPPORTS_SHARED_LIBS` property to `TRUE` in the global property scope. Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
2024-03-18 23:01:51 +08:00
# Do not build dynamically loadable libraries by default
cmake: Split toolchain configuration into pre-and post-DT Split up the toolchain configuration into two phases, generic and target. The 'generic' phase configures the toolchain just enough to be able to preprocess DT files. The 'target' phase completes the configuration with target-specific configuration. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-12-13 23:32:07 +08:00
set(BUILD_SHARED_LIBS OFF)
scripts: gen_handles.py: take device start symbol as argument. The current gen_handles.py script uses linker defined symbols. As preparation for support of more linkers the gen_tables.py now takes the device start symbol as argument. For example, armlink and ld uses different symbols. With ld those can be named explicitly, but for armlink the linker decides the names. For ld, Zephyr defines: __device_start For armlink, the symbol is defined as: Image$$<section name>$$Base Therefore knowledge of the linker symbol to be used must be passed to gen_handles.py so that the correct symbol can be used for locating devices. To support this change, the creation of the asm, compiler, compiler-cpp, linker targets has been moved from target_toolchain_flags.cmake to target_toolchain.cmake. All linkers has been updated to support the use of the device_start_symbol on the linker target. List of linkers updated: - ld - lld - arcmwdt Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-05-22 03:34:58 +08:00
# Custom targets for compiler and linker flags.
add_custom_target(asm)
add_custom_target(compiler)
add_custom_target(compiler-cpp)
add_custom_target(linker)
cmake: Split toolchain configuration into pre-and post-DT Split up the toolchain configuration into two phases, generic and target. The 'generic' phase configures the toolchain just enough to be able to preprocess DT files. The 'target' phase completes the configuration with target-specific configuration. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-12-13 23:32:07 +08:00
if(NOT (COMPILER STREQUAL "host-gcc"))
include(${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT}/target.cmake)
endif()
# The 'generic' compiler and the 'target' compiler might be different,
# so we unset the 'generic' one and thereby force the 'target' to
# re-set it.
unset(CMAKE_C_COMPILER)
unset(CMAKE_C_COMPILER CACHE)
cmake: Toolchain abstraction: use LINKER, introduce toolchain_ld_base toolchain_ld_base() represents flags that are fundamental to linking or otherwise does not belong in any further specified linker flag category. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-25 21:46:11 +08:00
# A toolchain consist of a compiler and a linker.
# In Zephyr, toolchains require a port under cmake/toolchain/.
# Each toolchain port must set COMPILER and LINKER.
# E.g. toolchain/llvm may pick {clang, ld} or {clang, lld}.
toolchain: improved toolchain abstraction for compilers and linker First abstraction completed for the toolchains: - gcc - clang Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-08-18 20:47:53 +08:00
add_custom_target(bintools)
cmake: Toolchain abstraction: Allow for out-of-tree cmake includes This allows for inclusion of out-of-tree toolchain cmake files relating to compiler and linker for both target and generic toolchains. The base path used was ZEPHYR_BASE, instead of TOOLCHAIN_ROOT, thus making it impossible to load the out-of-tree toolchain specific cmake files. In addition, the generic toolchain may now specify a generic cmake file for the linker, similar to the target toolchain linker. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-07-03 16:09:09 +08:00
include(${TOOLCHAIN_ROOT}/cmake/compiler/${COMPILER}/target.cmake OPTIONAL)
include(${TOOLCHAIN_ROOT}/cmake/linker/${LINKER}/target.cmake OPTIONAL)
cmake: Zephyr CMake package and CMake modules Create a cmake/modules folder containing all Zephyr CMake modules. All Zephyr cmake files that are included from boilerplate are now converted into CMake modules which can be individually loaded. The Zephyr CMake package is updated to support loading of individual CMake modules using the COMPONENTS argument to `find_package(Zephyr)`. If the COMPONENTS argument is not specified, the default Zephyr build system will load. If COMPONENTS is specified then, only those components and the dependencies will be loaded. If a Zephyr CMake module depends on another CMake module which has not been loaded, it will automatically be loaded. This allows us to modularize and reuse individual parts of the Zephyr CMake build system in a more flexible way in future. Such usage could be: - Higher livel multi image build system - Invocation of individual components, for example dts processing by twister without loading all build code - Doc build - Unittesting With this new CMake package and CMake module scheme then direct sourcing of boilerplate.cmake has been deprecated. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2021-12-17 00:13:54 +08:00
include(${ZEPHYR_BASE}/cmake/bintools/bintools_template.cmake)
cmake: Toolchain abstraction: Abstraction of binary tools, foundation. This forms the foundation for the abstraction of the binary tools, where the following steps are taken: - Move binary tool resolving, such as objcopy, objdump, readelf and so forth, out of compiler definitions and place in a dedicated binary tools folder with the binary tools supplier as subfolder, similar to the compiler and linker directories. - Create binary tool sets, gnu, host-gnu and llvm. - Each toolchain selects the required set of binary tools by setting BINTOOLS via its generic.cmake as it also does for compiler and linker. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-07-18 21:06:51 +08:00
include(${TOOLCHAIN_ROOT}/cmake/bintools/${BINTOOLS}/target.cmake OPTIONAL)
cmake: rework of target toolchain handling Follow-up: #41301 This commit is a rework and cleanup of the target toolchain handling in Zephyr CMake build system. Instead of directly loading code a CMake modules for target toolchain lookup, the target toolchain now follows the CMake `find_package()` pattern for finding the target toolchain. This makes it more clear which modules are responsible for finding tools and which modules provides build integration / features. The following tools can now be found using `find_package()`: - Target toolchain: find_package(TargetTools) Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2022-08-30 17:11:36 +08:00
cmake: improve Zephyr link phase Zephyr is a bare metal build where standard libs are disabled. This means that c and runtime libraries must manually be linked in. This has generally been handled by using CMake's link libraries handling but the issue with that is both de-duplication but also library link order. Standard libraries must be linked at last location to ensure symbols are always available, however this is not optimal with target_link_libraries() because this would ultimately require every library to know the c library to link with, which is not desired. Therefore, setup standard C and runtime library linking in linker CMake files for toolchains where this is required. This commit expands the principle introduced with toolchain abstraction, see PR#24851. This means that a toolchain implementation may specify standard C, runtime, C++, etc libraries, as well as their link order. Because a property approach is used, then Zephyr modules, such as the Picolibc module can adjust such properties. An optional `zephyr_linker_finalize()` macro is called at the end of Zephyr's CMakeList process and can be used by the toolchain implementation to define the final linker invocation. This aligns the linker handling flow to the principle introduced in PR#24851 and improves the flexibility and robustness of Zephyr build system. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2024-08-06 16:13:31 +08:00
include(${TOOLCHAIN_ROOT}/cmake/linker/target_template.cmake)
cmake: rework of target toolchain handling Follow-up: #41301 This commit is a rework and cleanup of the target toolchain handling in Zephyr CMake build system. Instead of directly loading code a CMake modules for target toolchain lookup, the target toolchain now follows the CMake `find_package()` pattern for finding the target toolchain. This makes it more clear which modules are responsible for finding tools and which modules provides build integration / features. The following tools can now be found using `find_package()`: - Target toolchain: find_package(TargetTools) Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2022-08-30 17:11:36 +08:00
set(TargetTools_FOUND TRUE)
set(TARGETTOOLS_FOUND TRUE)