-
Notifications
You must be signed in to change notification settings - Fork 9.1k
doc: Zephyr out-of-tree module.yml examples #28583
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -96,4 +96,35 @@ Glossary of Terms | |
| term storage rather than copying it into RAM, saving writable memory for | ||
| dynamic data and not the static program code. | ||
|
|
||
| Zephyr downstream module | ||
| A Zephyr module that the :file:`zephyr` repository default configuration | ||
| and default manifest file are **not** aware of. | ||
|
|
||
| Zephyr manifest module | ||
| A Zephyr module which also contains one or more west manifest files. | ||
|
|
||
| Zephyr module | ||
| A YAML file named :file:`zephyr/module.yml` and all the content it | ||
| references, which define the extensions to be hooked into the Zephyr | ||
| infrastructure. | ||
|
|
||
| Zephyr Project module | ||
| A Zephyr module managed by the Zephyr Project. These modules will | ||
| be hosted at the Zephyr project organization on Github. | ||
|
|
||
| Zephyr upstream module | ||
| A Zephyr module that the :file:`zephyr` repository default configuration | ||
| and default manifest file are aware of. | ||
|
|
||
| :makevar:`ZEPHYR_MODULES` | ||
| The Zephyr build system CMake variable through which a list of paths to | ||
| Zephyr modules that should be included in the current build. | ||
|
|
||
| :makevar:`ZEPHYR_EXTRA_MODULES` | ||
| The Zephyr build system CMake variable through which paths to | ||
| Zephyr modules may be provided. This is provided to support module | ||
| development tangential to how :makevar:`ZEPHYR_MODULES` is being used. | ||
|
Comment on lines
125
to
126
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. or it can be used in combination to Could be, as example, when working with the source for a closed source stack.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good to know. Please suggest replacement text if you feel that needs to be captured.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. will do some thinking. |
||
| (See :ref:`Integrate modules in Zephyr build system <modules>` | ||
| for a detailed description of the intended use case.) | ||
|
|
||
| .. _System on a chip: https://en.wikipedia.org/wiki/System_on_a_chip | ||
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.
imo we consider the whole project a Zephyr module when it contains a
zephyr/module.ymlfile, and not just the file itself.The file is just used to identify that this project is a Zephyr module, and the content of the file defines how it should be integrated, as example, is it a DTS, board, soc root ? should it be included in the build flow (CMakeLists/Kconfig) ? should it integrate into twister.
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.
@tejlmand I started with your impression, then asked if it still made sense for repositories like project_chip and bacnet-stack, which have substantial content for non-Zephyr platforms and environments. It seems the content not reachable by the Zephyr glue code is beyond any Zephyr-module policies. I just didn't want developers in other Open Source projects to think all of their repository needed to comply with Zephyr policies.
Would you still like this changed?
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 think we need something in between. Cause I find the current description too limiting.
Personally, I would still refer to the project as a Zephyr module, although not all of the code in there may be used by Zephyr.
Just like https://github.com/zephyrproject-rtos/mbedtls is a Zephyr module, but as the code is developed by ARM, then the code itself will not comply with Zephyr policies.
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.
@tejlmand Suggestions welcome, and I can align with a more generic definition. Since we can imply a valid
zephyr/module.ymlfrom repos with bothzephyr/CMakeLists.txtandzephyr/Kconfig(and/or deprecate it), how about:"A repository with a valid
zephyr/module.yml" ?