board/*/kconfig: Fix boards on kconfig blocklist

[MrKevinWeiss]

Contribution description

This should (eventually) test and pass all non-deprecated boards when using kconfig modeling.

Testing procedure

Murdock green

Issues/PRs references

Related to #16875

[MrKevinWeiss]

Hmmm currently the esps are failing due to RIOT_CI_BUILD changing the dependency resolution.

I thought we can get around it by just importing a riot-ci-build.config but, as importing configs can't have any ifs or something, it seems like this will need to be solved by adding a CONFIG_RIOT_CI_BUILD that can alter the kconfig dependency resolution. Maybe this could also be solved with some macro magic or something.

[gschorcht]

Hmmm currently the esps are failing due to RIOT_CI_BUILD changing the dependency resolution.

😟 I am really sorry for this inconvenience. These conditional dependencies were just a trick to cover all optional esp_* modules in CI compilation without defining additional virtual boards which would increase again the compile time in Murdock. This became necessary because we noticed several times that after a series of changes provided by different PRs, the compilation suddenly fails when optional modules are enabled because they were not covered when the PRs were compiled in CI.

Another idea (first approach in PR #12971) was to clone a number of test applications which use these optional modules, but it seemed to be not reasonable to have duplicated code just for compilation tests.

To be honest, I felt that the virtual boards approach would have been the coolest one and the clearest.

[MrKevinWeiss]

I am really sorry for this inconvenience.

Don't be. This just points out an issue that we should be able to solve. This is not the only env var that would change the dependency resolution I would image. Now that I think of it, it should be solved like DEVELHELP. Let me check it out!

[MrKevinWeiss]

We will see about this. I am not so convinced of the HAVE_RIOT_CI_BUILD_ESP_* symbols, especially the implementation of HAVE_RIOT_CI_BUILD_ESP_I2C_HW. It would be good to get some feedback from @leandrolanzieri as he figured out that design pattern. But I can wait for that review. (worst case we flag it and fix it later...)

[MrKevinWeiss]

Ahh it passed... That seemed almost too easy.

[MrKevinWeiss]

I will run a full build if the CI is free I guess.

[MrKevinWeiss]

I will run a full build if the CI is free I guess.

I spoke too soon 😆

[MrKevinWeiss]

OK looks better, should not contain any conflicting esp changes.

[MrKevinWeiss]

I think everything should be in order now. Any remaining issues?

[MrKevinWeiss]

ugg I guess this should be paused until the design patterns PR is finished.

[MrKevinWeiss]

The issue is how to have default selectable modules that don't contain variants (ie no choices). This currently will hide the prompt during menuconfig if the default is selected. The 2 proposed solutions are selecting from the HAVE_ which has the problem that all dependencies need to be repeated there, imply would not actually updated the values if the default is selected. Or adding a comment, which takes a few extra lines but seems to be the cleanest solution.

[MrKevinWeiss]

OK, simplified the drivers as per our best understanding of the design patterns.

If everything looks good may I squash?

[leandrolanzieri]

Looks mostly good, please address the comments and squash directly @MrKevinWeiss!

[MrKevinWeiss]

Just needs an ack :)

[fjmolinas]

LGTM, trusting CI

[leandrolanzieri]

ACK!

[MrKevinWeiss]

Thanks for the review!