This can reduce the amount of boilerplate required. Instead of introducing a macro such as QRIO_MODULE dependent on CIRCUITPY_QRIO and then adding an expansion of it in MICROPY_PORT_BUILTIN_MODULES_STRONG_LINKS, one simply writes in the bindings __init__.c file:
MP_REGISTER_MODULE(MP_QSTR_qrio, qrio_module, CIRCUITPY_QRIO);
where the first item is the module name as a qstr, the second item is the module's globals, and the third is the preprocessor macro that expands to (1) when enabled.
This can be done on a piecemail basis, and this bug would be closed once the last one is completed. I didn't prepare a checklist here, but basically everything in shared-bindings should be done unless a reason not to is identified.
Besides reducing boilerplate slightly, it also eases including modules with no hardware dependency in the "unix" build, which enables them to be testable. In time, such testability could be applied to bitmaptools and atexit, to name just two examples.
This can reduce the amount of boilerplate required. Instead of introducing a macro such as
QRIO_MODULEdependent onCIRCUITPY_QRIOand then adding an expansion of it inMICROPY_PORT_BUILTIN_MODULES_STRONG_LINKS, one simply writes in the bindings__init__.cfile:where the first item is the module name as a qstr, the second item is the module's globals, and the third is the preprocessor macro that expands to (1) when enabled.
This can be done on a piecemail basis, and this bug would be closed once the last one is completed. I didn't prepare a checklist here, but basically everything in shared-bindings should be done unless a reason not to is identified.
Besides reducing boilerplate slightly, it also eases including modules with no hardware dependency in the "unix" build, which enables them to be testable. In time, such testability could be applied to bitmaptools and atexit, to name just two examples.