2019-04-06 21:08:09 +08:00
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
|
2018-12-19 23:01:05 +08:00
|
|
|
# No official documentation exists for the "Generic" value, except their wiki.
|
|
|
|
#
|
|
|
|
# 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".
|
|
|
|
set(CMAKE_SYSTEM_NAME Generic)
|
|
|
|
|
|
|
|
# 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
|
2018-12-13 23:32:07 +08:00
|
|
|
set(CMAKE_SYSTEM_PROCESSOR ${ARCH})
|
|
|
|
|
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})
|
|
|
|
|
|
|
|
# We are not building dynamically loadable libraries
|
2018-12-13 23:32:07 +08:00
|
|
|
set(BUILD_SHARED_LIBS OFF)
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
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}.
|
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: 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)
|
2018-12-13 23:32:07 +08:00
|
|
|
|
|
|
|
# Uniquely identify the toolchain wrt. it's capabilities.
|
|
|
|
#
|
|
|
|
# What we are looking for, is a signature definition that is defined
|
|
|
|
# like this:
|
2019-04-25 21:45:39 +08:00
|
|
|
# * Toolchains with the same signature will always support the same set
|
|
|
|
# of flags.
|
2018-12-13 23:32:07 +08:00
|
|
|
# It is not clear how this signature should be constructed. The
|
|
|
|
# strategy chosen is to md5sum the CC binary.
|
|
|
|
file(MD5 ${CMAKE_C_COMPILER} CMAKE_C_COMPILER_MD5_SUM)
|
|
|
|
set(TOOLCHAIN_SIGNATURE ${CMAKE_C_COMPILER_MD5_SUM})
|