-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
Zephyr package modules #41301
Conversation
efa19df
to
881e671
Compare
84ca6d8
to
bcec317
Compare
bcec317
to
01ece8d
Compare
There was a problem hiding this 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.
cmake/modules/kernel.cmake
Outdated
# Zephyr Kernel CMake module. | ||
# | ||
# This is the main Zephyr Kernel module which is resposible for creation of | ||
# Zephyr libraries and the Zephyr executeable. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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:
zephyr/cmake/app/boilerplate.cmake
Line 591 in 5fda6a3
project(Zephyr-Kernel VERSION ${PROJECT_VERSION}) |
zephyr/cmake/app/boilerplate.cmake
Line 611 in 5fda6a3
set(KERNEL_NAME ${CONFIG_KERNEL_BIN_NAME}) |
In Kconfig:
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. |
Line 109 in 5fda6a3
hex "Kernel load size" if !USE_DT_CODE_PARTITION |
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.
There was a problem hiding this comment.
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"?
01ece8d
to
ccbc688
Compare
9549828
to
1c57242
Compare
Thanks.
Good point, and done. To everyone else, the reason for using the name
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great now!
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]>
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]>
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]>
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]>
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:
In Zephyr sysbuild / multi image #40555 it will remove the need for a boilerplate file like this: https://github.com/zephyrproject-rtos/zephyr/blob/641b86999750f1ed71fffda1da7c47387db22c23/sysbuild/cmake/boilerplate.cmake as this can now be handled as part of Zephyr package loading.
This will allow twister to generate the zephyr.dts tree and do filtering and not invoking a complete CMake configuration.
This opens for the use-case referenced by @mbolivar-nordic on Discord https://discord.com/channels/720317445772017664/733037738068148335/914952860192632852
See a PR for this work: cmake: package_helper CMake script #41302
find_package(ZephyrUnittest)
as that can simply be loaded as specific module like:find_package(Zephyr COMPONENTS unittest)
With the improved Zephyr CMake package, it is now possible to do:
find_package(Zephyr)
: Will load a standard build setup as alwaysfind_package(Zephyr COMPONENTS unittest)
: Load specific unittest build setupfind_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/