Remove Kconfig dependency modelling#20438
Conversation
benpicco
left a comment
There was a problem hiding this comment.
You probably want so squash that
|
Some tests are still failing, ya I will squash it... I guess it would be near impossible to review. |
|
@benpicco Ok, I squashed the best I could... Still not so easy to review but if all tests are passing I guess it should be OK 😉 @Teufelchen1 A bit after soft feature freeze but I hope it is OK. Keeping up with rebasing can be a bit of a challenge. |
| Set to enable code in RIOT that does safety checking which might not be | ||
| needed in a production environment but helps in the development | ||
| process. | ||
| comment "Ideally, make a PR to add them to the Kconfig." |
|
maybe we can jump the queue on this one... |
|
rebased |
|
oh boy am I sad... OK back at it. |
|
Not only does the gcoap test fail, but also it seems like there are some issues with |
|
hmmm, way less of a problem than I though... just a conflict in values for |
|
Hmmm the failed test builds on my machine. Maybe something to do with rust on a CI machine? |
|
🎉 Thx! |
|
I didn't think I would make it. Nice that it is finally over. I will also prioritize any issues or bugs this may have causes. |
|
Thank you for bringing the Kconfig transition to a close! |
Contribution description
As discussed on the forum and agreed upon in the VMA among other forms of communications we are removing the dependency modelling of Kconfig. As it was never part of the "production" RIOT and only available as an experimental feature (
TEST_KCONFIG=1) I do not think we need to deprecate it.This PR should remove everything dependency related but preserve all "kconfig for configurations" aspects.
It is a step in the direction of having "one source of truth" for configurations, many configurations that were only exposed when
TEST_KCONFIG=1are now exposed in a regular build (ie,depends on MODULE_*->depends on USEMODULE_). These configurations are still not being used by default (for any test that does not have an app.config file present) as to not slow down the CI before the release but will be switched very soon.There are quite some things needed in order to do this right:
MODULE_andPACKAGE_configs and symbol references within remaining filesCONFIG_that have been implemented under the dep modelling to use the make dep modelling (ie.MODULE_->USEMODULE_)Inject all the HAS_CPU* type featuresTesting procedure
Green murdock and a lot of looking through
Issues/PRs references
Needs #20497