2022-02-24 20:00:55 +08:00
|
|
|
# Uniquely identify the toolchain wrt. its capabilities.
|
2020-12-11 20:22:05 +08:00
|
|
|
#
|
|
|
|
|
# What we are looking for, is a signature definition that is defined
|
|
|
|
|
# like this:
|
|
|
|
|
# * The MD5 sum of the compiler itself. A MD5 checksum is taken of the content
|
|
|
|
|
# after symlinks are resolved. This ensure that if the content changes, then
|
|
|
|
|
# the MD5 will also change (as example toolchain upgrade in same folder)
|
|
|
|
|
# * The CMAKE_C_COMPILER itself. This may be a symlink, but it ensures that
|
|
|
|
|
# multiple symlinks pointing to same executable will generate different
|
|
|
|
|
# signatures, as example: clang, gcc, arm-zephyr-eabi-gcc, links pointing to
|
|
|
|
|
# ccache will generate unique signatures
|
|
|
|
|
# * CMAKE_C_COMPILER_ID is taking the CMake compiler id for extra signature.
|
|
|
|
|
# * CMAKE_C_COMPILER_VERSION will ensure that even when using the previous
|
|
|
|
|
# methods, where an upgraded compiler could have same signature due to ccache
|
|
|
|
|
# usage and symbolic links, then the upgraded compiler will have new version
|
|
|
|
|
# and thus generate a new signature.
|
|
|
|
|
#
|
|
|
|
|
# Toolchains with the same signature will always support the same set of flags.
|
|
|
|
|
#
|
|
|
|
|
file(MD5 ${CMAKE_C_COMPILER} CMAKE_C_COMPILER_MD5_SUM)
|
|
|
|
|
set(TOOLCHAIN_SIGNATURE ${CMAKE_C_COMPILER_MD5_SUM})
|
|
|
|
|
|
|
|
|
|
# Extend the CMAKE_C_COMPILER_MD5_SUM with the compiler signature.
|
|
|
|
|
string(MD5 COMPILER_SIGNATURE ${CMAKE_C_COMPILER}_${CMAKE_C_COMPILER_ID}_${CMAKE_C_COMPILER_VERSION})
|
|
|
|
|
set(TOOLCHAIN_SIGNATURE ${TOOLCHAIN_SIGNATURE}_${COMPILER_SIGNATURE})
|
|
|
|
|
|
2021-10-01 03:01:57 +08:00
|
|
|
# Load the compile features file which will provide compile features lists for
|
|
|
|
|
# various C / CXX language dialects that can then be exported based on current
|
|
|
|
|
# Zephyr Kconfig settings or the CSTD global property.
|
|
|
|
|
include(${CMAKE_CURRENT_LIST_DIR}/compiler/compiler_features.cmake)
|
|
|
|
|
|
2022-02-24 20:00:55 +08:00
|
|
|
# Loading of templates are strictly not needed as they do not set any
|
2020-04-28 14:33:37 +08:00
|
|
|
# properties.
|
2022-02-24 20:00:55 +08:00
|
|
|
# They purely provide an overview as well as a starting point for supporting
|
2020-04-28 14:33:37 +08:00
|
|
|
# a new toolchain.
|
|
|
|
|
include(${CMAKE_CURRENT_LIST_DIR}/compiler/compiler_flags_template.cmake)
|
|
|
|
|
include(${CMAKE_CURRENT_LIST_DIR}/linker/linker_flags_template.cmake)
|
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(${CMAKE_CURRENT_LIST_DIR}/linker/linker_libraries_template.cmake)
|
2020-04-28 14:33:37 +08:00
|
|
|
|
2020-08-18 20:47:53 +08:00
|
|
|
# Configure the toolchain flags based on what toolchain technology is used
|
|
|
|
|
# (gcc, host-gcc etc.)
|
|
|
|
|
include(${TOOLCHAIN_ROOT}/cmake/compiler/${COMPILER}/compiler_flags.cmake OPTIONAL)
|
|
|
|
|
include(${TOOLCHAIN_ROOT}/cmake/linker/${LINKER}/linker_flags.cmake OPTIONAL)
|
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/${LINKER}/linker_libraries.cmake OPTIONAL)
|