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

39 lines
1.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: 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_ifndef(XTOOLS_TOOLCHAIN_PATH "$ENV{XTOOLS_TOOLCHAIN_PATH}")
set( XTOOLS_TOOLCHAIN_PATH ${XTOOLS_TOOLCHAIN_PATH} CACHE PATH "")
assert( XTOOLS_TOOLCHAIN_PATH "XTOOLS_TOOLCHAIN_PATH is not set")
set(TOOLCHAIN_HOME ${XTOOLS_TOOLCHAIN_PATH})
set(COMPILER gcc)
cmake: Toolchain abstraction: introduce LINKER variable The LINKER variable is introduced to follow the same logic and flow as the existing COMPILER variable: That is, each TOOLCHAIN is responsible for choosing COMPILER and LINKER. Currently, Zephyr's build system is hardcoded for GNU ld. Reflect this in LINKER by letting all existing toolchains use GNU ld. 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 20:22:00 +08:00
set(LINKER ld)
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
set(BINTOOLS gnu)
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
# Choose one of the toolchains in 'TOOLCHAIN_HOME' at random to use as
# a 'generic' toolchain until we know for sure which toolchain we
docs: fix misspelling across the tree Found a few annoying typos and figured I better run script and fix anything it can find, here are the results... Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-19 02:45:40 +08:00
# should use. Note that we can't use ARCH to distinguish between
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
# toolchains because choosing between iamcu and non-iamcu is dependent
# on Kconfig, not ARCH.
cmake: xtools: use SoC name in path to xtensa toolchain Xtensa requires building a new toolchain for a specific SoC. By default xtools built Xtensa toolchains all have prefix of xtensa-zephyr-elf. In order to distinguish different toolchains, they are now placed in their own directories under their SoC name. This allows us to have multiple Xtensa toolchains targeting multiple SoCs. The additional level in path name is introduced in SDK v0.11 and sdk-ng master. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-10-08 02:34:29 +08:00
if("${ARCH}" STREQUAL "xtensa")
file(GLOB toolchain_paths ${TOOLCHAIN_HOME}/xtensa/*/*)
else()
file(GLOB toolchain_paths ${TOOLCHAIN_HOME}/*)
endif()
xtools: exclude "sources" when searching xtools output dir When using xtools as toolchain, cmake searches the toolchain home directory. However, if the first toolchain directory does not begin with any character before "s", "sources" (if exists) would become the first directory being probed. Since it does not conform to "arch-vendor-abi" naming, cmake would fail. So exclude "sources" from the list to avoid this issue. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-02-23 12:42:37 +08:00
list(REMOVE_ITEM toolchain_paths ${TOOLCHAIN_HOME}/sources)
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
list(GET toolchain_paths 0 some_toolchain_path)
cmake: xtools: use SoC name in path to xtensa toolchain Xtensa requires building a new toolchain for a specific SoC. By default xtools built Xtensa toolchains all have prefix of xtensa-zephyr-elf. In order to distinguish different toolchains, they are now placed in their own directories under their SoC name. This allows us to have multiple Xtensa toolchains targeting multiple SoCs. The additional level in path name is introduced in SDK v0.11 and sdk-ng master. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-10-08 02:34:29 +08:00
get_filename_component(some_toolchain_root "${some_toolchain_path}" DIRECTORY)
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
get_filename_component(some_toolchain "${some_toolchain_path}" NAME)
set(CROSS_COMPILE_TARGET ${some_toolchain})
set(SYSROOT_TARGET ${CROSS_COMPILE_TARGET})
cmake: xtools: use SoC name in path to xtensa toolchain Xtensa requires building a new toolchain for a specific SoC. By default xtools built Xtensa toolchains all have prefix of xtensa-zephyr-elf. In order to distinguish different toolchains, they are now placed in their own directories under their SoC name. This allows us to have multiple Xtensa toolchains targeting multiple SoCs. The additional level in path name is introduced in SDK v0.11 and sdk-ng master. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-10-08 02:34:29 +08:00
set(CROSS_COMPILE ${some_toolchain_root}/${CROSS_COMPILE_TARGET}/bin/${CROSS_COMPILE_TARGET}-)
set(SYSROOT_DIR ${some_toolchain_root}/${SYSROOT_TARGET}/${SYSROOT_TARGET})
toolchain: espressif: mark newlib support false newlib is not supported with this toolchain, so mark it as such and filter tests based on the variable defined in the toolchain file. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-01-09 21:47:25 +08:00
set(TOOLCHAIN_HAS_NEWLIB ON CACHE BOOL "True if toolchain supports newlib")
cmake: xtools: use SoC name in path to xtensa toolchain Xtensa requires building a new toolchain for a specific SoC. By default xtools built Xtensa toolchains all have prefix of xtensa-zephyr-elf. In order to distinguish different toolchains, they are now placed in their own directories under their SoC name. This allows us to have multiple Xtensa toolchains targeting multiple SoCs. The additional level in path name is introduced in SDK v0.11 and sdk-ng master. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-10-08 02:34:29 +08:00
unset(some_toolchain_root)
unset(some_toolchain)