[RFC] boards/cpu: model of 'common' directories

[cladmi]

Description

Boards based on a common board sometime only use Makefile.include but not Makefile.dep, or do not process Makefile.features even if it exist.
Sometime a common Makefile.dep does not exist at the beginning but may be created in the future and not all boards get updated.
Some boards do not use the board_common_abcd module implemented.

This leads to asking is this really in common ?

Because of this, the current model for common boards and common cpu is not completely clear as some board could only partially use a common board for good or bad reasons.

Questions

Makefile including files

Is it something we would like to have, that if a board/cup uses any of the Makefile.include|Makefile.dep|Makefile.features it must also process the other files (if they exist) ?

If a board/cpu was always processing all files, we can think of defining a board as

    board
       |-> board/common/1
       |-> board/common/2
           |-> board/common/3
       |-> cpu
           |-> cpu/common/1
               |-> cpu/common/2

If then this hierarchy can be defined recursively and be consistent, it could remove the need to re-include and add to DIRS all the common files in each Makefile|Makefile.dep|Makefile.features|Makefile.include and leave this to central files.

Also easily give "by which parts is my board/cpu implemented".
It could currently be deduced from MAKEFILE_LIST but would not mean all features or dependencies are used.

Examples

Some of the files not using Makefile.features were found during #11477

• common/msba2, common/remote, common/msb-430 not using a common Makefile.features. Which was problematic when moving CPU/CPU_MODEL to it. TODO PR, currently in Tracking: move CPU/CPU_MODEL to Makefile.features #11477
• boards/arduino-leonardo does not process common/arduino-atmega/Makefile.include|.dep
• boards/jiminy-mega256rfr2/ does not process
• boards/calliope-mini does not process common/nrf51/Makefile.dep
• nucleo-f410rb and nucleo-f411re do not process common/nucleo64/Makefile.features
• chronos declares dependency in Makefile.include and has not Makefile.dep
• common/wsn430 declares a dependency in Makefile.include and has not Makefile.dep

TODO:

Find a script that really shows if a board/cpu does not use all the files from the common. And so ignores the non existing common files.

# Simplified version that miss some parts
git grep -l 'common/.*/Makefile.' boards/  | sed 's/Makefile.*//' | uniq -c | grep -v '3 '
      2 boards/arduino-leonardo/
      2 boards/avsextrem/
      2 boards/calliope-mini/
      1 boards/common/arduino-atmega/
      1 boards/common/kw41z/
      1 boards/common/nucleo144/
      1 boards/common/nucleo32/
      1 boards/common/nucleo64/
      2 boards/firefly/
      1 boards/frdm-k22f/
      1 boards/frdm-k64f/
      2 boards/jiminy-mega256rfr2/
      1 boards/mega-xplained/
      1 boards/msb-430/
      1 boards/msb-430h/
      2 boards/msba2/
      2 boards/nucleo-f410rb/
      2 boards/nucleo-f411re/
      2 boards/remote-pa/
      2 boards/remote-reva/
      2 boards/remote-revb/
      1 boards/waspmote-pro/
      2 boards/wsn430-v1_3b/
      2 boards/wsn430-v1_4/

A more verbose output that does not merge including two different common files, but even more false positive.

git grep 'common/.*/Makefile.' boards/ | sed 's/Makefile.[a-z]*/Makefile.xxx/g' | uniq -c | sed 's/Makefile..*//' | grep -v '3 '

Always defining each file

Question, should we move toward all the boards, cpu and commons always define Makefile.dep/Makefile.features/Makefile.include ?

This way it allows a board to use a common one and be future proof as if a dependency is added, it will always be processed. Otherwise, each time a new common included file is created all boards using that common one must be updated at the same time.

common code without function namespacing

Despite the namespacing requirement https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions#naming boards and cpu modules do not respect it.

Some boards/common define board_init directly, and have board.h and periph_conf.h headers which leads to the board not being able to extend a common board without duplicating the files.

Would it be good to change this and define board_common_abcd_init to allow re-using it ? Same for the headers and all.

Re-use of a board as a common board

Currently due to the previous issue with namespacing and that the fact that all boards define the board module and all cpu the cpu module, same for drivers/periph so a board cannot be used as a 'common' board. Having each board defining the board_boardname module and then the board_boardname_init would allow re-using that code.

A generic board module should be in riot to call the right board_boardname_init function.

Tracking updates

• phynode-kw41z/Makefile.include does not use the common/kw41z/Makefile.include phynode-kw41z/Makefile.include does not use the common/kw41z/Makefile.include #11616
• ...

For the phynode-kw41z it was updated so that the USEMODULE += boards_common_kw41z is not put in common anymore but let on the board to include the module or not.

Related issues

This was currently found while moving CPU/CPU_MODEL to Makefile.features.

• Tracking: move CPU/CPU_MODEL to Makefile.features Tracking: move CPU/CPU_MODEL to Makefile.features #11477
• phynode-kw41z/Makefile.include does not use the common/kw41z/Makefile.include phynode-kw41z/Makefile.include does not use the common/kw41z/Makefile.include #11616

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[fjmolinas]

Re-opening this is still valid IMO.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[fjmolinas]

re-open