This commit reverts a breaking change in CMAKE_SYSTEM_NAME introduced by
"Zephyr" back to "Generic") and removes the file
`cmake/modules/Platform/Zephyr`.
Both changes in the aforementioned PR were only introduced to ultimately
modify the value of the global CMake property TARGET_SUPPORTS_SHARED_LIBS
for the special case of building for Xtensa with LLEXT.
The modification of CMAKE_SYSTEM_NAME is considered a breaking change
because it has the potential to alter the build of any non-trivial project
that previously checked for the "Generic" system identifier as
corresponding to Zephyr - for example by doing
`if (CMAKE_SYSTEM_NAME STREQUAL "Generic")`. Such builds may now break in
many ways including silently when there is no `else()` clause with a
`message()` to alert the user that a whole configuration block had been
skipped.
In essence, that CMAKE_SYSTEM_NAME modification was only introduced in
order to have CMake to load `cmake/modules/Platform/Zephyr.cmake` which in
turn adjusted the value of TARGET_SUPPORTS_SHARED_LIBS.
But the use of a CMake platform file like this is ineffective for
non-trivial projects where one or more top level CMake `project()` calls
may happen before the first call to `find_package(Zephyr)` because in such
cases CMAKE_MODULE_PATH will not have been modified yet to contain the
path to <Zephyr_ROOT>/cmake/modules and thus no platform file will be
include by CMake.
This patch moves the conditional override of TARGET_SUPPORTS_SHARED_LIBS
needed by some archs (e.g. Xtensa) into the `kernel.cmake` module which
is known to be the first call to `project()` that enables any language and
thus the one that must come before any artifact target can be defined.
Note commit 64e7d85 added a Kconfig to specify the object type of llext
being built, so it's not tied to the arch anymore but to the
CONFIG_LLEXT_TYPE_ELF_SHAREDLIB option.
Signed-off-by: Nicolas Lebedenco <nicolas@lebedenco.net>
That call to enable_languages() is passed C CXX ASM which misleads the
reader into thinking that the three languages are enabled in that call but
at that point only ASM is actually because C and CXX were already
implicitly enabled by the call to project() above. The suggested change
removes the misleading C CXX arguments but we could as well make it clear
in the project() call by passing LANGUAGES C CXX.
Signed-off-by: Nicolas Lebedenco <nicolas@lebedenco.net>
When `toolchain_is_ok` fails, the error message points the user at the
CMake logs. But those logs will be empty if the user tried to compile
more than once (typically: cleans everything and tries again). So tell
the user that cleaning the toolchain cache is required to see the error.
Tell the user to "move" the cache instead of removing it in case
technical support needs the cache for forensics.
Some finicky toolchains can be "non-deterministic" and fail
_sometimes_. For instance a license server can be flaky, or the
toolchain can require an "elaborate" set of environment variables
triggering some configuration "trial-and-error". In such a
non-deterministic case deleting the cache is enough to get rid of the
issue and move on! Looking at logs is not even required; even
better. Once the toolchain cache believes that the toolchain works, any
future toolchain glitch will be obvious at actual compilation time.
To test all this:
```
# Verify that the toolchain can compile a dummy file, if it is not we
# won't be able to test for compatibility with certain C flags.
-zephyr_check_compiler_flag(C "" toolchain_is_ok)
+zephyr_check_compiler_flag(C "-fubar" toolchain_is_ok)
assert(toolchain_is_ok "The toolchain is unable to build a dummy C file.\
```
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Static code analyser (SCA) tools are important in software development.
CMake offers built-in support for some tools, such as cppcheck and
clang-tidy.
Other tools, such as sparse, are not directly supported.
This commit provides a uniform way for users to specify a supported
SCA using `ZEPHYR_SCA_VARIANT=<tool>` which is consistent with how
toolchains are specified.
ZEPHYR_SCA_VARIANT can be set using `-D` or in environment.
Support for an SCA tool is done in `cmake/sca/<tool>/sca.cmake`.
SCA_ROOT can be used to specify additional search paths when looking up
implementation for a tool. SCA_ROOT can also be specified in
`zephyr/module.yml` as setting. This makes it possible to provide SCA
tool implementation as part of a Zephyr module.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Follow-up: #41301
This commit is a rework and cleanup of the target toolchain handling in
Zephyr CMake build system.
Instead of directly loading code a CMake modules for target toolchain
lookup, the target toolchain now follows the CMake `find_package()`
pattern for finding the target toolchain.
This makes it more clear which modules are responsible for finding tools
and which modules provides build integration / features.
The following tools can now be found using `find_package()`:
- Target toolchain: find_package(TargetTools)
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Optional way for generating symbols file using binutils. This file will
be generated on demand for tests which will then be parsed by twister to
create an accurate test plan from the listed testcase/suites.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Create a cmake/modules folder containing all Zephyr CMake modules.
All Zephyr cmake files that are included from boilerplate are now
converted into CMake modules which can be individually loaded.
The Zephyr CMake package is updated to support loading of individual
CMake modules using the COMPONENTS argument to `find_package(Zephyr)`.
If the COMPONENTS argument is not specified, the default Zephyr build
system will load.
If COMPONENTS is specified then, only those components and the
dependencies will be loaded.
If a Zephyr CMake module depends on another CMake module which has not
been loaded, it will automatically be loaded.
This allows us to modularize and reuse individual parts of the Zephyr
CMake build system in a more flexible way in future.
Such usage could be:
- Higher livel multi image build system
- Invocation of individual components, for example dts processing by
twister without loading all build code
- Doc build
- Unittesting
With this new CMake package and CMake module scheme then direct
sourcing of boilerplate.cmake has been deprecated.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
