Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zephyr package modules #41301

Merged

Conversation

tejlmand
Copy link
Collaborator

@tejlmand tejlmand commented Dec 17, 2021

This is a complete Zephyr CMake package and CMake modules overhaul.

The intention with this major cleanup is to make the build system more modular in a way so that it can easier be reused through the Zephyr package mechanism.

Use-cases for this work is:

With the improved Zephyr CMake package, it is now possible to do:
find_package(Zephyr) : Will load a standard build setup as always
find_package(Zephyr COMPONENTS unittest): Load specific unittest build setup
find_package(Zephyr COMPONENTS dts): Load only dts module (and its direct dependencies)
find_package(Zephyr COMPONENTS extensions west zephyr_module): Load specific modules(and their direct dependencies), for example sysbuild use-case/

gmarull
gmarull previously approved these changes Dec 17, 2021
cmake/kernel.cmake Outdated Show resolved Hide resolved
cmake/modules/unittest.cmake Outdated Show resolved Hide resolved
Copy link
Member

@carlescufi carlescufi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent initiative!

The only thing I would like to ask is that you fully qualify "Zephyr module" vs "CMake module" in every instance of each that could be prone to confusion with the other.

Comment on lines 5 to 8
# Zephyr Kernel CMake module.
#
# This is the main Zephyr Kernel module which is resposible for creation of
# Zephyr libraries and the Zephyr executeable.
Copy link
Member

@henrikbrixandersen henrikbrixandersen Dec 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps kernel.cmake is a bit misleading as we often refer to a subset of the Zephyr repository codebase as the "kernel", whereas this CMake module is not specific to that part of the codebase?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to agree with you that it would be nice to have the kernel name referring to a specific sub-part of the Zephyr repo.
I'm very open to other proposals, but so far kernel.cmake was the best I could find that refers to the overall build of the system and the final executable.

We use the term kernel in a lot of places outside the kernel code base itself, for example:
The project name:

project(Zephyr-Kernel VERSION ${PROJECT_VERSION})

set(KERNEL_NAME ${CONFIG_KERNEL_BIN_NAME})

In Kconfig:

zephyr/Kconfig.zephyr

Lines 96 to 103 in 5fda6a3

hex "Kernel load offset" if !USE_DT_CODE_PARTITION
default $(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_CODE_PARTITION)) if USE_DT_CODE_PARTITION
default 0
help
This option specifies the byte offset from the beginning of flash that
the kernel should be loaded into. Changing this value from zero will
affect the Zephyr image's link, and will decrease the total amount of
flash available for use by application code.

hex "Kernel load size" if !USE_DT_CODE_PARTITION

zephyr/Kconfig.zephyr

Lines 361 to 362 in 5fda6a3

config KERNEL_BIN_NAME
string "The kernel binary name"

Because we are already using the term kernel to also refer to the overall project / image then I felt kernel was the best I could come up with, but other proposals are more than welcome.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we are already using the term kernel to also refer to the overall project / image then I felt kernel was the best I could come up with, but other proposals are more than welcome.

How about "core"?

@tejlmand tejlmand force-pushed the zephyr_package_modules branch 2 times, most recently from 9549828 to 1c57242 Compare December 20, 2021 09:10
@tejlmand
Copy link
Collaborator Author

Excellent initiative!

Thanks.

The only thing I would like to ask is that you fully qualify "Zephyr module" vs "CMake module" in every instance of each that could be prone to confusion with the other.

Good point, and done.

To everyone else, the reason for using the name CMake module here is because it's the official term used in CMake, ref:
https://cmake.org/cmake/help/latest/command/include.html#command:include

Load and run CMake code from a file or module.

include(<file|module> [OPTIONAL] [RESULT_VARIABLE <var>]
                      [NO_POLICY_SCOPE])

carlescufi
carlescufi previously approved these changes Dec 20, 2021
Copy link
Member

@carlescufi carlescufi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great now!

tejlmand added a commit to tejlmand/zephyr that referenced this pull request Sep 1, 2022
Follow-up: zephyrproject-rtos#41301

This commit is a rework and cleanup of the tools handling in Zephyr
CMake build system.

Instead of directly loading code a CMake modules for tool lookup, the
host tools now follows the CMake `find_package()` pattern for finding
programs / tools in module mode.

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()`:
- Zephyr-sdk        : find_package(Zephyr-sdk <version>)
- Generic host tools: find_package(HostTools)

This further allows us to decouple the `verify-toolchain` CMake script
part required by `twister` into a tool lookup module and a dedicated
CMake script which utilizes the lookup module.

Signed-off-by: Torsten Rasmussen <[email protected]>
tejlmand added a commit to tejlmand/zephyr that referenced this pull request Sep 1, 2022
Follow-up: zephyrproject-rtos#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 <[email protected]>
carlescufi pushed a commit that referenced this pull request Sep 1, 2022
Follow-up: #41301

This commit is a rework and cleanup of the tools handling in Zephyr
CMake build system.

Instead of directly loading code a CMake modules for tool lookup, the
host tools now follows the CMake `find_package()` pattern for finding
programs / tools in module mode.

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()`:
- Zephyr-sdk        : find_package(Zephyr-sdk <version>)
- Generic host tools: find_package(HostTools)

This further allows us to decouple the `verify-toolchain` CMake script
part required by `twister` into a tool lookup module and a dedicated
CMake script which utilizes the lookup module.

Signed-off-by: Torsten Rasmussen <[email protected]>
carlescufi pushed a commit that referenced this pull request Sep 1, 2022
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 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants