-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
Tool to compile entire subdirectory to .mpy files #3040
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
Comments
I'm not quite sure I follow the use/need of this tool: isn't it just a 1-line shell command? Eg something like |
Apparently not a one-line shell command, because it needs to pass arguments down to mpy-cross, be able to compile .mpy in place or in a dedicated (non existing) dir, then likely few more features pop up. But it definitely going to be pretty simple (for starters) Python script, and that point that we should standardize on it. |
This is all work for a Makefile, or whatever build system the user is using. Also, a user would want to install the files on the board which requires copying, something that we don't yet provide, so that would be the first thing to do (eg in pyboard.py). |
Right, and Makefile just calls that tool, instead of containing bunch of glitchy shell magic.
In my case, I just want to easily and cleanly get compiled bytecode to run with unix port, see We really can't go for advanced tools like #3034, and leave large basic gaps in developer convenience inbetween. I have a prototype of the tool, will post it for review tomorrow. |
Shell is much more widely supported than a Python script to do the same job. And such a script, if it existed, would want to check timestamps to only recompile those .py files that needed it, exactly what a Makefile is for.
Frozen .mpy is used only in the coverage build of unix, but you can also use it in the normal build if you define FROZEN_MPY_DIR. Did that work? If not it's bug that needs fixing. As for other ports that directly support frozen .mpy file (ie esp8266, stmhal) they work fine: just put your .py files in the modules/ directory. |
No. There's no standard shell - MacOSX, Wondows have different ones.
No such requirement for the initial version of the tool, mpy-cross is fast, so compiling couple of dozens of source files (on user request) is not a problem.
Unfortunately, Makefile can't have a target which depends on "all files matching a pattern in a subdir, recursively, including any additions or deletions", which leads to workarounds of different level of smartness, with it being a pure wonder when they work, and when they don't (which happens regularly), it looks like comments above. |
Yes, eventually it did. Apparently, frozen_mpy.c wasn't properly generated at the try # 1. |
Implemented in PR above. |
Hi there, we are just getting started with
As the reference to the actual PR somehow got lost, we just decided to re-add this reference for others also coming here. Last but not least, we would like to send kudos regarding the amazing system you are building with MicroPython over there. Keep up the spirit! With kind regards, |
STM32: Add port D to LQFP64
I think we should think of developers' experience using .mpy files and add a tool to convert entire directory/project to .mpy form. For starters, it can be written in Python. It would accept an input directory, and optionally, output directory to .mpy files (in the expected hierarchical form).
The text was updated successfully, but these errors were encountered: