patrick/zephyr
1
0
Fork 0
Code Issues Pull requests Actions 8 Packages Projects Releases Wiki Activity
zephyr/cmake/generic_toolchain.cmake

49 lines
1.9 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 15:08:09 +02:00
# SPDX-License-Identifier: Apache-2.0
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 10:05:20 +01:00
# Prevent CMake from testing the toolchain
set(CMAKE_C_COMPILER_FORCED 1)
set(CMAKE_CXX_COMPILER_FORCED 1)
cmake: Support custom out-of-tree toolchains Add a new optional TOOLCHAIN_ROOT cmake and environment variable to specify an alternative location for toolchain cmake files. When set, Zephyr will look for a toolchain cmake file located in: ${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT}.cmake Signed-off-by: François Delawarde <fnde@oticon.com>
2018-09-25 13:05:58 +02:00
if(NOT TOOLCHAIN_ROOT)
if(DEFINED ENV{TOOLCHAIN_ROOT})
# Support for out-of-tree toolchain
set(TOOLCHAIN_ROOT $ENV{TOOLCHAIN_ROOT})
else()
# Default toolchain cmake file
set(TOOLCHAIN_ROOT ${ZEPHYR_BASE})
endif()
endif()
cmake: ensure consistent behavior between x_ROOT settings Fixes: #23825 Today, BOARD, SOC, ARCH, DTS, KCONFIG, and TOOLCHAIN_ROOT can be specified by users or through other CMake files. It is not clear if relative paths are permitted and/or from where a relative path is constructed. Inside CMake, it is very easy to specify `${ZEPHYR_BASE}`, `${CMAKE_CURRENT_SOURCE_DIR}`, or similar, thus there is no reason to use relative path inside CMake, as it easy can lead to discussion on relative to what. For users manually invoking CMake using, `cmake ... <app-dir>` it is nice to have to possibility to specify a relative path. For this purpose, relative path are considered relative to the `APPLICATION_SOURCE_DIR`. This commit updates: - BOARD_ROOT - SOC_ROOT - ARCH_ROOT - DTS_ROOT - KCONFIG_ROOT - TOOLCHAIN_ROOT to allow paths relative to `APPLICATION_SOURCE_DIR` when specified with `-D<type>_ROOT=<relative-path>` Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-09-08 14:07:00 +02:00
zephyr_file(APPLICATION_ROOT TOOLCHAIN_ROOT)
cmake: Support custom out-of-tree toolchains Add a new optional TOOLCHAIN_ROOT cmake and environment variable to specify an alternative location for toolchain cmake files. When set, Zephyr will look for a toolchain cmake file located in: ${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT}.cmake Signed-off-by: François Delawarde <fnde@oticon.com>
2018-09-25 13:05:58 +02:00
cmake: Don't use the environment variable CFLAGS Some distros set the environment variable CFLAGS, this will accidentally affect Zephyr builds. To fix this we clear the environment variable from within the Zephyr build system for the duration of the CMake execution. Until now we have been instructing the user to clear it, but it is easier for the user if we clear it for him. The same applies to CXXFLAGS. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-09-03 10:54:16 +02:00
# Don't inherit compiler flags from the environment
cmake: Ignore LDFLAGS and AFLAGS from environment Zephyr does not use CFLAGS, CXXFLAGS, CPPFLAGS if they are defined in the environment but provides the option to pass them via extra cmake flags. The option is also for seen to pass AFLAGS and LDFLAGS as extra cmake flags but both of them are not ignored if they are defined in the environment which could lead to unexpected behaviour. As such lineup the behaviour between all the flags and ignore them, and generate a warning, if they are defined in the environment. Signed-off-by: Jan Van Winkel <jan.van_winkel@dxplore.eu>
2020-09-05 11:38:03 +02:00
foreach(var AFLAGS CFLAGS CXXFLAGS CPPFLAGS LDFLAGS)
cmake: Don't use the environment variable CFLAGS Some distros set the environment variable CFLAGS, this will accidentally affect Zephyr builds. To fix this we clear the environment variable from within the Zephyr build system for the duration of the CMake execution. Until now we have been instructing the user to clear it, but it is easier for the user if we clear it for him. The same applies to CXXFLAGS. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-09-03 10:54:16 +02:00
if(DEFINED ENV{${var}})
message(WARNING "The environment variable '${var}' was set to $ENV{${var}},
but Zephyr ignores flags from the environment. Use 'cmake -DEXTRA_${var}=$ENV{${var}}' instead.")
unset(ENV{${var}})
endif()
endforeach()
cmake: Set TOOLCHAIN_HOME for Zephyr's SDK Host-tools don't unconditionally set TOOLCHAIN_HOME anymore, but in case Zephyr's SDK toolchain is used, set TOOLCHAIN_HOME. Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
2019-03-08 13:52:11 +01:00
# Host-tools don't unconditionally set TOOLCHAIN_HOME anymore,
# but in case Zephyr's SDK toolchain is used, set TOOLCHAIN_HOME
if("${ZEPHYR_TOOLCHAIN_VARIANT}" STREQUAL "zephyr")
set(TOOLCHAIN_HOME ${HOST_TOOLS_HOME})
endif()
cmake: Support custom out-of-tree toolchains Add a new optional TOOLCHAIN_ROOT cmake and environment variable to specify an alternative location for toolchain cmake files. When set, Zephyr will look for a toolchain cmake file located in: ${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT}.cmake Signed-off-by: François Delawarde <fnde@oticon.com>
2018-09-25 13:05:58 +02:00
cmake: ensure consistent behavior between x_ROOT settings Fixes: #23825 Today, BOARD, SOC, ARCH, DTS, KCONFIG, and TOOLCHAIN_ROOT can be specified by users or through other CMake files. It is not clear if relative paths are permitted and/or from where a relative path is constructed. Inside CMake, it is very easy to specify `${ZEPHYR_BASE}`, `${CMAKE_CURRENT_SOURCE_DIR}`, or similar, thus there is no reason to use relative path inside CMake, as it easy can lead to discussion on relative to what. For users manually invoking CMake using, `cmake ... <app-dir>` it is nice to have to possibility to specify a relative path. For this purpose, relative path are considered relative to the `APPLICATION_SOURCE_DIR`. This commit updates: - BOARD_ROOT - SOC_ROOT - ARCH_ROOT - DTS_ROOT - KCONFIG_ROOT - TOOLCHAIN_ROOT to allow paths relative to `APPLICATION_SOURCE_DIR` when specified with `-D<type>_ROOT=<relative-path>` Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-09-08 14:07:00 +02:00
set(TOOLCHAIN_ROOT ${TOOLCHAIN_ROOT} CACHE STRING "Zephyr toolchain root" FORCE)
cmake: Support custom out-of-tree toolchains Add a new optional TOOLCHAIN_ROOT cmake and environment variable to specify an alternative location for toolchain cmake files. When set, Zephyr will look for a toolchain cmake file located in: ${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT}.cmake Signed-off-by: François Delawarde <fnde@oticon.com>
2018-09-25 13:05:58 +02:00
assert(TOOLCHAIN_ROOT "Zephyr toolchain root path invalid: please set the TOOLCHAIN_ROOT-variable")
cmake: Zephyr sdk package handling This commit introduces Zephyr SDK CMake config package. This removes the need for setting ZEPHYR_SDK_INSTALL_DIR and ZEPHYR_TOOLCHAIN_VARIANT when using Zephyr SDK in Linux. It also allows to introduces never SDKs without breaking Zephyr. For example, with this PR, the current Zephyr SDK is 0.11.1 but when releasing 0.12 then the current Zephyr will no longer built. This PR moves the Zephyr SDK CMake related code to the SDK and thus allowing to use newer SDKs, as long as they are backwards compatible. It also allows multiple SDK installations, and will automatically select the version closet to the required version. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-04-06 23:15:39 +02:00
# Set cached ZEPHYR_TOOLCHAIN_VARIANT.
build: deprecate ZEPHYR_GCC_VARIANT We want to support other toolchain not based on GCC, so the variable is confusing, use ZEPHYR_TOOLCHAIN_VARIANT instead. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-02-11 21:36:21 +01:00
set(ZEPHYR_TOOLCHAIN_VARIANT ${ZEPHYR_TOOLCHAIN_VARIANT} CACHE STRING "Zephyr toolchain variant")
cmake: Re-introduce support for CROSS_COMPILE CROSS_COMPILE is a KBuild feature that was dropped during the CMake migration. It is now re-introduced. Documentation for it is still lacking, but at least it now behaves as expected. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-08 17:06:42 +01:00
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# Configure the toolchain based on what SDK/toolchain is in use.
cmake: Introduce host toolchain for POSIX arch Make POSIX's host toolchain follow convention of other toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-01-09 17:24:35 +01:00
include(${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT}/generic.cmake)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: Introduce optional Kconfig for toolchains Allow a given toolchain to specify Kconfig options that might be relevant to a feature available in that toolchain. For example, the ARM embedded GNU toolchain supports two variants of newlib and you select the smaller one via a spec file. We can use a Kconfig option like HAS_NEWLIB_LIBC_NANO to convey that this feature is supported by that toolchain. We look for the toolchain Kconfig in ${TOOLCHAIN_KCONFIG_DIR}/Kconfig, and default TOOLCHAIN_KCONFIG_DIR to: ${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT}) toolchain specific cmake files can override the default if needed. Additionally tweaked the zephyr/generic.cmake to use ${CMAKE_CURRENT_LIST_DIR} to reduce some duplication. Signed-off-by: Kumar Gala <kumar.gala@linaro.org> Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-01-24 16:39:40 +01:00
set_ifndef(TOOLCHAIN_KCONFIG_DIR ${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# Configure the toolchain based on what toolchain technology is used
cmake: toolchain: Misc. comment cleanups Sync the outdated comments with the code. E.g. there is no toolchain-clang.cmake, but there is a toolchain-host-gcc.cmake. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-08 17:05:26 +01:00
# (gcc, host-gcc etc.)
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 10:09:09 +02:00
include(${TOOLCHAIN_ROOT}/cmake/compiler/${COMPILER}/generic.cmake OPTIONAL)
include(${TOOLCHAIN_ROOT}/cmake/linker/${LINKER}/generic.cmake OPTIONAL)
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 15:06:51 +02:00
include(${TOOLCHAIN_ROOT}/cmake/bintools/${BINTOOLS}/generic.cmake OPTIONAL)
Reference in a new issue Copy permalink