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:
Torsten Rasmussen 2021-12-16 17:13:54 +01:00 committed by Marti Bolivar
commit 61453e4a58
26 changed files with 223 additions and 114 deletions

View 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)