[PoC] Module dependency modelling using Kconfig #14055
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
96f2b23 to
479cf8b
Compare
This adds not-visible modules like 'sys' or 'cpu' and some other modules that usually are active like 'core_msg', and 'auto_init'.
This models cortexm_common and cortexm_common_periph modules. It also models the architecture-specific symbols and defines CPU common symbols when using this architecture.
479cf8b to
bf21ed6
Compare
|
Rescheduled in favor of release notes, which I want to get into the release branch ASAP |
aabadie
reviewed
Jul 30, 2020
| @@ -8,3 +8,9 @@ config BOARD | |||
| string | |||
| help | |||
| Name of the currently selected board. | |||
|
|
|||
| config MOD_BOARD | |||
There was a problem hiding this comment.
Can't we use an explicit MODULE prefix instead of MOD ?
There was a problem hiding this comment.
Yes, once the migration is completed we could just change that. But the MODULE_ prefix is currently being used to get the information of the modules added via USEMODULE, which allows to show only relevant configurations:
Lines 94 to 102 in 06dca07
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution description
This PR is a proposal of how we could model module's dependencies in Kconfig. Although there are many commits, this models the minimum to get
examples/gnrc_networkingto compile forsamr21-xpro. It's to have an idea of how this can look like.As presented before, the approach for module selection is bottom-up. This means that all dependencies of a module need to be active in order to select that module. Opposite to the current approach where some modules are selected and its dependencies are included (some sort of top-down approach).
Documentation has been added and split into:
Reviewing this
I tried to make each commit as self-contained as possible, mostly modelling a module per commit. Nonetheless there are a lot of changes so I will point out some things which might be nice to take a look at:
I based most of the dependencies on our Makefile.dep files, but the current modelling is not definitive as some dependencies might still be missing, and some modules that are always used may be hidden.
Example of configuration
Selecting source seed and implementation for random
Usage
examples/gnrc_networkingrunTEST_KCONFIG=1allows to switch between the usage of Kconfig and Makefile.dep to get the module list to compile.Kconfig will load the configuration file present in the application folder.
If you need to clean the application take into account that for now
make cleanandmake allshould be called separately.