Makefile.dep: disable stdio_% modules before they are included

[fjmolinas]

Contribution description

This PR moves all stdio_% dependency resolution to is own file to cleanup inclusion order and better isolate the dependencies. Maybe #13469 will lead to a parent module and the dependencies can be moved to that Makefile.dep?

This PR also fixes disabling of stdio modules when this is done not by using DISABLE_MODULE directly but by the use of a conflicting USEMODULE.

Before this PR because of recursive declaration, on the first pass through Makefile.dep stdio_rtt would be added and then removed from USEMODULE this would lead to having in USEMODULE the dependencies of stdio_rtt but not the module itself.

By disabling right away we make sure its dependencies are note added.

Testing procedure

• testing procedure in Makefile.dep: DEFAULT_MODULE += stdio_rtt will always load dependencies - even if other stdio is selected #13460

• If the new Makefile is not liked I can keep the same changes in Makefile.dep

• I haven't changed the order in which stdio modules are included so there should be no change here, a green Murdock should be enough.

Issues/PRs references

Fixes #13460
Related to #13469

[miri64]

Tested with some boards. Is the following of any concern?

$ USEMODULE=stdio_null BOARD=feather-m0 make -C examples/hello-world/ info-modules 
make: Entering directory '/home/mlenders/Repositories/RIOT-OS/RIOT/examples/hello-world'
auto_init
---> auto_init_usbus
board
boards_common_samd21-arduino-bootloader
core
core_init
core_msg
core_panic
cortexm_common
cortexm_common_periph
cpu
newlib
newlib_nano
newlib_syscalls_default
periph
periph_common
periph_gpio
periph_init
periph_init_common
periph_init_gpio
periph_init_init
periph_init_pm
periph_pm
pm_layered
sam0_common_periph
stdio_null
sys
usb_board_reset
make: Leaving directory '/home/mlenders/Repositories/RIOT-OS/RIOT/examples/hello-world'

[miri64]

Other than my change request, I'm fine with the overall concept of this PR.

[miri64]

Just an idea I head, when working on #13649: Might it make sense to have a dedicated module list for the STDIO module(s), e.g. STDIO_MODULES += stdio_rtt?

[miri64]

Adapted from Makefile.dep, I know, but does this dependency even make sense? Why enforce a STDIO when newlib is there? AFAIK newlib should just work fine without STDIO, or am I mistaken?

[fjmolinas]

Adapted from Makefile.dep, I know, but does this dependency even make sense? Why enforce a STDIO when newlib is there? AFAIK newlib should just work fine without STDIO, or am I mistaken?

This might just be a way of saying if newlib is included then default stdio is stdio_uart.

[miri64]

Yea, but basically this is why stdio_null is necessary, right? Why does there need to be a stdio at all?

[fjmolinas]

Yea, but basically this is why stdio_null is necessary, right? Why does there need to be a stdio at all?

It doesn't but most users expect to see something if they do make term so it makes sense to usually include it.

Maybe more can be done towards cleaning this up by actually using DEFAULT_MODULE here, but I would rather leave it for later.

[miri64]

Yeahyeah, this was just a thought, not actually requesting a solution here.

[fjmolinas]

Tested with some boards. Is the following of any concern?

Yes it is but thats an issue with #12304, where there is no way of properly disabling arduino-bootloader and boards/common/samd21-arduino-bootloader/Makefile.dep is always included for those boards. So the modules you point out are not included by stdio_cdc_acm

[miri64]

Tested with some boards. Is the following of any concern?

Yes it is but thats an issue with #12304, where there is no way of properly disabling arduino-bootloader and boards/common/samd21-arduino-bootloader/Makefile.dep is always included for those boards. So the modules you point out are not included by stdio_cdc_acm

Then let's go with the current approach. Please squash!

[miri64]

ACK!

[fjmolinas]

Just an idea I head, when working on #13649: Might it make sense to have a dedicated module list for the STDIO module(s), e.g. STDIO_MODULES += stdio_rtt?

Can you elaborate? would these be a list of supported stdio?

[miri64]

Just an idea I head, when working on #13649: Might it make sense to have a dedicated module list for the STDIO module(s), e.g. STDIO_MODULES += stdio_rtt?

Can you elaborate? would these be a list of supported stdio?

My thinking was that STDIO_MODULES would semantically work like DEFAULT_MODULES just be a distinct list. The reason I picked modules instead of module (singular) is to be prepared for #13469 already ;-).

[miri64]

The idea is mostly to keep the semantics of DEFAULT_MODULES clean (which, when the build system itself starts disabling defaults by itself starts me to wonder: is it really a default then?)

[fjmolinas]

The idea is mostly to keep the semantics of DEFAULT_MODULES clean (which, when the build system itself starts disabling defaults by itself starts me to wonder: is it really a default then?)

I understand, maybe we can discus that in #13651? What you propose could be a good way of separating special cases of DEFAULT_MODULEs (whether we use that name or not). But at the same time we could say the same thing about all USEMODULEs somehow.

[fjmolinas]

Thanks for the review!

[miri64]

I've updated #13469 for the things discussed here (under "More considerations")