-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Remove Kconfig dependency modelling #20438
Conversation
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 |
f4441e0
to
d265330
Compare
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=1
are 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