This commit allows a project to specify a given set of Kconfig targets
prior to sourcing kconfig.cmake.
This allows for greater flexibility when re-using kconfig.cmake in
other projects.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit allows for specifying a dedicated Kconfig namespace, for
example: <namespace>_CONFIG
This namespace will then be used for handling loading of configuration
files into CMake configure scope, as well as handling of CMake cache
variables when set using `-D<namespace>_CONFIG_<var>=<value>`.
This allows greater flexibility when re-using the cmake/kconfig.cmake
in other projects.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Allow build system to define an alternative defconfig file.
This allows reusing the existing kconfig.cmake file in other projects,
such as multi image builds.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Propagate the board revision to Kconfig via the environment.
This is useful for application code to have access to for similar
reasons that CONFIG_BOARD is useful.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Fixes: #43378
Move the exporting of ZEPHYR_TOOLCHAIN_VARIANT from the custom target to
the COMMON_KCONFIG_ENV_SETTINGS variable.
This ensures that the setting is exported both when running the initial
kconfiglib parsing but also on later menuconfig / guiconfig invocations.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
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>
