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