boards: move remaining uses of USEMODULE from Makefile.include to Makefile.dep

[aabadie]

Contribution description

This PR moves all remaining uses of USEMODULE += <module> from boards Makefile.include to the corresponding Makefile.dep.

Testing procedure

• A green Murdock
• for each modified board, check the list of modules included in a build and compare to master

Issues/PRs references

#9913

[smlng]

did this one got lost? or did I overlooked it?

[aabadie]

no idea, did you change this recently ?

[gschorcht]

• for each modified board, check the list of modules included in a build and compare to master

IMHO, we should use again dist/tools/buildsystem_sanity_check/save_all_dependencies_resolution_variables.sh. I will try it later today.

[aabadie]

Wait a bit @gschorcht, Murdock is reporting a lot of failures. I'd like to fix them first.

[gschorcht]

@aabadie I have the script already running, but for current master first. This will be needed anyway.

[gschorcht]

Wait a bit @gschorcht, Murdock is reporting a lot of failures. I'd like to fix them first.

As I have seen only for 4 boards acd52832, ruuvitag, wsn430-v1_3b, wsn430-v1_4 and for only one test esp32-olimex-evb.

[aabadie]

@gschorcht, I pushed a fix that I hope should improve the situation.

[gschorcht]

@gschorcht, I pushed a fix that I hope should improve the situation.

I will take a look to the problem with the esp32-olimex-evb board.

[gschorcht]

@aabadie I figured out a problem for all ESP32 boards in board.h headers where board_common.h was included inside the extern "C" linkage block. Even though PR #13301 fixes the problem, the reason the compilation error occurred with this PR and not in the master is a wrong module:

The esp32-olimex-32 has an Ethernet interface which should be used default netdev. That's why module esp_eth is enabled if the netdev_default module is defined. However, depending on this module, some compile options must be set in Makefile.include.

And here we encounter the problem of the order in which Makefile.include and Makefile.dep are read. It must be known in Makefile.include whether esp_eth, esp_wifi or esp_now are used in order to set some compile options correctly. However, the dependencies in Makefile.dep are read after Makefile.include has been read. Therefore, all dependencies for these modules must be kept in Makefile.include for the moment until we change this order.

Maybe we could solve this problem using FEATURES_OPTIONAL and FEATURES_PROVIDED.

[aabadie]

@gschorcht, I'll remove the changes related to the esp32 board for the moment.

I agree that having features for esp_eth, esp_wifi, esp_now could help with the dependency resolution.

[aabadie]

No more build failures on Murdock, OK to squash @gschorcht ?

[gschorcht]

Should we first have the results of dist/tools/buildsystem_sanity_check/save_all_dependencies_resolution_variables.sh?

[aabadie]

Should we first have the results of dist/tools/buildsystem_sanity_check/save_all_dependencies_resolution_variables.sh?

That would help indeed. Let's wait for the results.

[gschorcht]

I ran dist/tools/buildsystem_sanity_check/save_all_dependencies_resolution_variables.sh for this PR and the current master. The output generated with

BOARD="${board}" make -C "${RIOTBASE}/${application}" dependency-debug

is completely identical. However the output from

DEPENDENCY_DEBUG=1 make -C "${RIOTBASE}/${application}" info-boards-supported

differs slightly. But the only difference is that the list of used module in USEMODULE contains an additional entry boards_common_* with this PR for the boards that use a common board definition, for example boards_common_nucleo for nucleo-* boards.

Without having a deep look why the USEMODULE list for info-boards-supported differs, it seems that the dependencies per application and board are exactly the same. Furthermore, it contains only an additional entry for boards_common_* which seems to be correct. Therefore, I would say that everything is fine.

[gschorcht]

@aabadie Please squash.

[aabadie]

Done

[aabadie]

It's all green @gschorcht !

[gschorcht]

ACK

[gschorcht]

@aabadie Thanks for the contribution.