cmake: Zephyr CMake package and CMake modules
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>
This commit is contained in:
parent
96b3e4d0c4
commit
61453e4a58
26 changed files with 223 additions and 114 deletions
88
cmake/modules/zephyr_default.cmake
Normal file
88
cmake/modules/zephyr_default.cmake
Normal file
|
@ -0,0 +1,88 @@
|
|||
# SPDX-License-Identifier: Apache-2.0
|
||||
#
|
||||
# Copyright (c) 2021, Nordic Semiconductor ASA
|
||||
|
||||
# This CMake module will load all Zephyr CMake modules in correct order for
|
||||
# default Zephyr build system.
|
||||
#
|
||||
# Outcome:
|
||||
# See individual CMake module descriptions
|
||||
|
||||
include_guard(GLOBAL)
|
||||
|
||||
# The code line below defines the real minimum supported CMake version.
|
||||
#
|
||||
# Unfortunately CMake requires the toplevel CMakeLists.txt file to define the
|
||||
# required version, not even invoking it from a CMake module is sufficient.
|
||||
# It is however permitted to have multiple invocations of cmake_minimum_required.
|
||||
cmake_minimum_required(VERSION 3.20.0)
|
||||
|
||||
message(STATUS "Application: ${APPLICATION_SOURCE_DIR}")
|
||||
|
||||
find_package(ZephyrBuildConfiguration
|
||||
QUIET NO_POLICY_SCOPE
|
||||
NAMES ZephyrBuild
|
||||
PATHS ${ZEPHYR_BASE}/../*
|
||||
NO_CMAKE_PATH
|
||||
NO_CMAKE_ENVIRONMENT_PATH
|
||||
NO_SYSTEM_ENVIRONMENT_PATH
|
||||
NO_CMAKE_PACKAGE_REGISTRY
|
||||
NO_CMAKE_SYSTEM_PATH
|
||||
NO_CMAKE_SYSTEM_PACKAGE_REGISTRY
|
||||
)
|
||||
|
||||
# Prepare user cache
|
||||
include(python)
|
||||
include(user_cache)
|
||||
|
||||
# Load Zephyr extensions
|
||||
include(extensions)
|
||||
include(version) # depends on hex.cmake
|
||||
|
||||
#
|
||||
# Find tools
|
||||
#
|
||||
|
||||
include(west)
|
||||
include(ccache)
|
||||
|
||||
# Load default root settings
|
||||
include(root)
|
||||
|
||||
#
|
||||
# Find Zephyr modules.
|
||||
# Those may contain additional DTS, BOARD, SOC, ARCH ROOTs.
|
||||
# Also create the Kconfig binary dir for generated Kconf files.
|
||||
#
|
||||
include(zephyr_module)
|
||||
|
||||
include(boards)
|
||||
include(shields)
|
||||
include(arch)
|
||||
include(configuration_files)
|
||||
|
||||
include(verify-toolchain)
|
||||
include(host-tools)
|
||||
|
||||
# Include board specific device-tree flags before parsing.
|
||||
include(${BOARD_DIR}/pre_dt_board.cmake OPTIONAL)
|
||||
|
||||
# DTS should be close to kconfig because CONFIG_ variables from
|
||||
# kconfig and dts should be available at the same time.
|
||||
#
|
||||
# The DT system uses a C preprocessor for it's code generation needs.
|
||||
# This creates an awkward chicken-and-egg problem, because we don't
|
||||
# always know exactly which toolchain the user needs until we know
|
||||
# more about the target, e.g. after DT and Kconfig.
|
||||
#
|
||||
# To resolve this we find "some" C toolchain, configure it generically
|
||||
# with the minimal amount of configuration needed to have it
|
||||
# preprocess DT sources, and then, after we have finished processing
|
||||
# both DT and Kconfig we complete the target-specific configuration,
|
||||
# and possibly change the toolchain.
|
||||
include(generic_toolchain)
|
||||
include(dts)
|
||||
include(kconfig)
|
||||
include(soc)
|
||||
include(target_toolchain)
|
||||
include(kernel)
|
Loading…
Add table
Add a link
Reference in a new issue