Ok, sorry for the delay and happy new year everyone!
In my option the biggest problem was the lack of a shared positive outlook on what Kconfig would brings us
Agreed, when it was first introduced the belief is everyone would be working and contributing to it. However, like so many things in RIOT, there was only one champion at a time which can make things harder when the work isn’t so exciting.
in the end it looked like we’d get slower builds
It looked like that because the testing was so thorough. In fact, the only thing that Kconfig would have affected would be the initial
info board-supported command used for the CI to determine what should work or not. If the migration would be complete and the structure would allow for a board wildcard entry (solved by Zephyr) it would be no different that what we currently would have with make. Comparing the hashes (which required multiple builds) did catch many issues not only in dependency modelling but also in varying configurations.
a more brittle config surface
I would say more structured, once one gets used to it failing early and being able to properly describe why something failed is a great asset. There were some constraints with the language that made some things very hard though (no circular dependencies being our biggest issue). The way we implemented it though, opposed to Zephyr which was completely bottom up, still allowed us quite a lot of reliable options…
In combination with the pain it caused on everyone submitting a PR with some new functionality who then also had to model it into Kconfig,
I agree with this… It simply dragged for too long. We should learn from this and rather have something like the i2c embargo where there is a small pause that forces many to finish rather then let something operate along side, forcing duplicate work.
I’m glad to see it gone.
It would have been nice to have all done and working properly but it just would take too many resources for not enough gain for most of the RIOT developers use cases (probably menuconfig would only be used by newer users).
Will you take care of sending the Kconfig removal PRs?
I can do that or at least review others work.
disable Kconfig builds in CI (so we can get those PRs stuck on Kconfig issues in)
That is the most important and should be pretty easy!
remove all Kconfig /
I think you mean all
app.config.test files since we still will use if for generic configurations using the dependency resolution of
make to handle the various config values that require knowledge of when modules or packages are being used.
clean the build system from the remains of Kconfig
I can get rid of anything we won’t need.
My understanding from the discussion at the VMA was that we “drop Kconfig altogether”, not only the dependency modelling part.
That isn’t what I had in mind. The config exposure works and is nice, no reason to remove that work.