-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
top: Replace MICROPY_PORT_BUILTIN_MODULES with MP_REGISTER_MODULE. #8566
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
print( | ||
( | ||
"#if ({enabled_define})\n" | ||
" extern const struct _mp_obj_module_t {obj_module};\n" | ||
" #undef {mod_def}\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean that if two or more modules with the same name are enabled, then the last one (according to sorted()
) "wins"?
Not a big deal, but is seems like in the vast majority of the cases, the 3rd parameter is 1 or could be 1, so perhaps we should just drop this parameter? |
You mean the |
OK, maybe I misunderstood how the code generator works. |
In most cases the I could try and come up with a varargs macro that makes that last parameter optional (default to 1). |
There are probably better ways to spend your time. 😉
This is why I thought we could just eliminate the parameter altogether. But if there are a few special cases where this doesn't work and can't be worked around by adding a |
Note that #include "common_board_files/modfoo.c`
... And then |
I've rebased this and updated the renesas-ra port to use it.
*blinks* ...I guess that's a good argument for making |
For example, ussl can come from axtls or mbedtls. If neither are enabled then don't try and set an empty definition twice, and only include it once in MICROPY_REGISTERED_MODULES. Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
_onewire, socket, and network were previously added by the port rather than objmodule.c. Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
Signed-off-by: Jim Mussared <[email protected]>
This functionality is now replaced with MP_REGISTER_MODULE. Signed-off-by: Jim Mussared <[email protected]>
Thanks for updating, now merged. |
@robert-hh Thanks. I will take a look ASAP. |
No need to have two different ways of registering modules. Simplifies mpconfigport.h and makes it consistent across all ways of defining modules (built-in, extmod, port, board, user-c-module).
It might be good to extend makemodulesdefs.py to also handle module constants (and maybe root pointers?) in the future.