-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
zephyr: Build MicroPython as a cmake target. #6542
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
ea1bb5e
to
3b88c47
Compare
Thanks for looking into this, it does look quite good, a good step to make. It is similar to #6392 (using an ExternalProject) but I think the approach here is cleaner because here there is no dependency on make, it's all pure cmake. Well, except for the qstr processing needing to run the C preprocessor, that is tricky. It seems that cmake doesn't have a portable/generic way of specifying that a file needs preprocessing, and so qstr preprocessing needs to be defined as a custom command that runs I think I have a solution which is less of a hack but still not that great. The fix looks like this (which needs to be cleaned up but gives you the idea): diff --git a/py/mkrules.cmake b/py/mkrules.cmake
index 8822cbeee..72134bef1 100644
--- a/py/mkrules.cmake
+++ b/py/mkrules.cmake
@@ -46,12 +46,23 @@ add_custom_command(
# Generate qstrs
+get_property_and_add_prefix(micropython_includes_raw ${MICROPYTHON_TARGET} INCLUDE_DIRECTORIES "-I")
+process_flags(C micropython_includes_raw micropython_includes)
+get_property_and_add_prefix(micropython_definitions_raw ${MICROPYTHON_TARGET} COMPILE_DEFINITIONS "-D")
+process_flags(C micropython_definitions_raw micropython_definitions)
+zephyr_get_include_directories_for_lang(C includes)
+zephyr_get_system_include_directories_for_lang(C system_includes)
+zephyr_get_compile_definitions_for_lang(C definitions)
+zephyr_get_compile_options_for_lang(C options)
+
+set(THE_FLAGS ${micropython_includes} ${micropython_definitions} ${includes} ${system_includes} ${definitions} ${options})
+
# If any of the dependencies in this rule change then the C-preprocessor step must be run.
# It only needs to be passed the list of SOURCE_QSTR files that have changed since it was
# last run, but it looks like it's not possible to specify that with cmake.
add_custom_command(
OUTPUT ${MPY_QSTR_DEFS_LAST}
- COMMAND ${CMAKE_C_COMPILER} -E \$\(C_INCLUDES\) \$\(C_FLAGS\) \$\(C_DEFINES\) -DNO_QSTR ${SOURCE_QSTR} > ${MPY_GENHDR_DIR}/qstr.i.last
+ COMMAND ${CMAKE_C_COMPILER} -E ${THE_FLAGS} -DNO_QSTR ${SOURCE_QSTR} > ${MPY_GENHDR_DIR}/qstr.i.last
DEPENDS ${MPY_MODULEDEFS}
${SOURCE_QSTR}
VERBATIM
@@ -74,7 +85,7 @@ add_custom_command(
add_custom_command(
OUTPUT ${MPY_QSTR_DEFS_PREPROCESSED}
- COMMAND cat ${MPY_PY_QSTRDEFS} ${MPY_QSTR_DEFS_COLLECTED} | sed "s/^Q(.*)/\"&\"/" | ${CMAKE_C_COMPILER} -E \$\(C_INCLUDES\) \$\(C_FLAGS\) \$\(C_DEFINES\) - | sed "s/^\\\"\\(Q(.*)\\)\\\"/\\1/" > ${MPY_QSTR_DEFS_PREPROCESSED}
+ COMMAND cat ${MPY_PY_QSTRDEFS} ${MPY_QSTR_DEFS_COLLECTED} | sed "s/^Q(.*)/\"&\"/" | ${CMAKE_C_COMPILER} -E ${THE_FLAGS} - | sed "s/^\\\"\\(Q(.*)\\)\\\"/\\1/" > ${MPY_QSTR_DEFS_PREPROCESSED}
DEPENDS ${MPY_QSTR_DEFS_COLLECTED}
VERBATIM
) With that patch I was able to build Zephyr using west/ninja. As for the frozen code issue, that should be much easier to fix. |
py/mkrules.cmake
Outdated
# last run, but it looks like it's not possible to specify that with cmake. | ||
add_custom_command( | ||
OUTPUT ${MPY_QSTR_DEFS_LAST} | ||
COMMAND ${CMAKE_C_COMPILER} -E \$\(C_INCLUDES\) \$\(C_FLAGS\) \$\(C_DEFINES\) -DNO_QSTR ${SOURCE_QSTR} > ${MPY_GENHDR_DIR}/qstr.i.last |
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.
This was already commented upon, but I wanted to second the necessity for not using generator-specific constructs in the CMake logic. This breaks non-Makefile generators, and is also fragile for the Makefile-based generators as well since it makes assumptions which may not hold true if the internal implementation details change. Additionally, it's using global options rather than target-specific compile options.
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.
Yes I completely agree. I think the above-mentioned fix should be a good solution for now.
This will work for zephyr, but how will it work for the esp32 port? |
3b88c47
to
b56bb25
Compare
I pushed an update to fix this properly |
py/mkrules.cmake
Outdated
add_custom_command( | ||
OUTPUT ${MPY_MPVERSION} | ||
COMMAND ${CMAKE_COMMAND} -E make_directory ${MPY_GENHDR_DIR} | ||
COMMAND python3 ${MPY_DIR}/py/makeversionhdr.py ${MPY_MPVERSION} |
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.
Please use FindPython3, i.e. find_package(Python3 REQUIRED COMPONENTS Interpreter)
.
In a virtualenv, the Python 3 interpreter might not have a "3" suffix, and this leads to build failure. Please use ${Python3_EXECUTABLE}
instead of hardcoding the name, and this should work in all situations.
This applies to the other instances, below.
The variable |
I've now improved the core cmake files, they can be found on the
@MaureenHelm would you be able to update this PR based on this new cmake code? To get the qstr preprocessing working I think you can add something like this to the end of
If you can't get to it let me know and I'll make a new PR based on this one. |
One final portability issue is the use of backslashes with sed. The following change makes it use CMake primitives directly, avoiding the need for lots of escaping. While I put the scripts inline in the CMakeLists.txt to keep everything in one place, they could be easily split out if desired which would make the quoting there less complex as well. With this change, it's possible to build on Windows with ninja (on top of all the other changes).
|
b56bb25
to
876aa36
Compare
@dpgeorge I've updated it, but I'm having trouble getting the qstr preprocessing to work. Would you mind having a look? |
I opened https://github.com/NXPmicro/micropython/pull/1/files as a way to provide some suggestions for making the qstr preprocessing work portably, plus a few other tweaks. I hope it's helpful. |
I pushed another portability fix (use "cmake -E touch" as a portable alternative to "touch") to the above PR, and also adjusted the path for one of the intermediate qstr files. |
876aa36
to
7741bc2
Compare
I finally got this to work, but it required a change on the zephyr side. See zephyrproject-rtos/zephyr#29935
@rleigh-lumiradx Thank you. I think you should submit the sed changes directly to the upstream micropython repo. They're orthogonal changes to mine so they should apply cleanly, and that way you can take credit for the enhancement in the git history. |
Great, thanks! I did spend quite some time trying to get this to work, with no success. My last resort (which is not too bad) was going to be to modify |
Updates the zephyr port build instructions and CI to use the latest zephyr release tag. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
The core cmake rules use custom commands to invoke qstr processing scripts. For the zephyr port, it's possible that list arguments to these commands may contain generator expressions, therefore we need to expand them properly. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Disables frozen source modules in the zephyr port. They are deprecated in the makefile rules and not implemented in the new cmake rules. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Removes zephyr port build files that aren't being used anymore. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
7741bc2
to
65b5fc0
Compare
Refactors the zephyr build infrastructure to build MicroPython as a cmake target, using the recently introduced core cmake rules. This change makes it possible to build the zephyr port like most other zephyr applications using west or cmake directly. It simplifies building with extra cmake arguments, such as specifying an alternate conf file or adding an Arduino shield. It also enables building the zephyr port anywhere in the host file system, which will allow regressing across multiple boards with the zephyr twister script. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
65b5fc0
to
930ef70
Compare
Rebased to master now that the esp32 cmake changes have been merged.
Pulled in #6797 to pick up the zephyr fix for this issue (needed to pass CI) This PR is now ready to go! |
Thank you! |
Add wifi.radio.tx_power
Extends #6473 to build Micropython as a cmake target in the Zephyr port. This is an alternative to #6392, which builds MicroPython as a cmake ExternalProject.
There are minor issues to fix around the ninja build system generator (which
west
uses by default) and frozen content, but overall I think having core cmake rules in MicroPython simplifies the port build nicely.Tested on the
mimxrt1050_evk
board.