Fixes: #40389
Update toolchain handling to use zephyr_get() to ensure consistent
handling of CMake cache variables, environment variable, and CMake
local variables.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Move include paths and add new target_include_directories to support
backwards compatibility:
* /include -> /include/zephyr
example: <irq.h> -> <zephyr/irq.h>
Issue #41543
Signed-off-by: Yuval Peress <peress@google.com>
Instead of setting XCC_USE_CLANG=1, this patch adds xcc-clang toolchain
that is basically xcc using the clang compiler.
Initially, the new toolchain simply includes files from current xcc
toolchain and (re)sets some variables. This should be a more scalable
approach to diverge the toolchains in the future than placing
"if($ENV{XCC_USE_CLANG})" at several places.
It should also help to filter tests that run (or not) exclusively with
the clang variant of XCC on twister.
The XCC_USE_CLANG flag is documented as deprecated, and a message is
emitted during build if still in use. Its new behaviour is to instruct
Zephyr to use `xcc-clang` toolchain.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
GCC-based XCC uses GNU Assembler (xt-as). However, CMake doesn't
recognize it when invoking through xt-xcc. This results in CMake
going through all possible combinations of command line arguments
while invoking xt-xcc to determine assembler vendor. This multiple
invocation of xt-xcc unnecessarily lengthens the CMake phase of
build, especially when XCC needs to obtain license information
from remote licensing servers. So here forces the assembler ID
to be GNU to speed things up a bit.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Some toolchain variants come with no clang support, so do not assume
clang by default and enable this using the enviornment variable
XCC_USE_CLANG.
export XCC_USE_CLANG=1
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Print the name of the discovered toolchain as well as the variable
used to initialize it.
This is nice to know when doing remote support, since users will
sometimes misconfigure their toolchain and not know what that means.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The XCC toolchain may come with Clang front-end depending on
how it's built. Currently, the only SoC/board using XCC is
the intel_s1000_crb and its XCC toolchain comes with Clang
3.9.0 which has a lot better support for C99 and C++11 than
the portion based on GCC 4.2 (which does not even support
C++11). So this change attempts to use the Clang portion
instead of GCC if the Clang executable exists.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
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>
Ensure that xcc is at parity with gcc and clang by inferring missing
definitions based on those that it already provides.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
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>
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>
Contrary to all other toolchains, the xcc toolchain had a hardocded
installation path. Replace this with XTENSA_TOOLCHAIN_PATH so users can
install in different locations.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
XCC is based on xcc, but is nothing like gcc and his many differences.
Instead of ifdeffing the gcc code with Xcc specifics, maintain it
standalone.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
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>
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>
Torsten Rasmussen