ESP32 micropython port build with relative path to external user C-modules was failed
Checks
-
I agree to follow the MicroPython Code of Conduct to ensure a safe and respectful space for everyone.
-
I've searched for existing issues matching this bug, and didn't find any.
Port, board and/or hardware
esp32 port, ESP32-boards of any kind, I guess
MicroPython version
MicroPython v1.22.2-dirty on 2024-04-18; Generic ESP32 module with ESP32
Reproduction
make USER_C_MODULES=../../examples/usercmodule/micropython.cmake
Expected behaviour
Make process failed with error message like a:
modules not found in the path <specified_path>
Observed behaviour
During the build, make changed current directory and relative path to micropython.cmake file turns out to be incorrect
Additional Information
Need expand relative path of USER_C_MODULES variable, to absolute path before passed it to the ./py/usermod.cmake as described below:
In the file ./ports/esp32/Makefile , line 41:
ifdef USER_C_MODULES
CMAKE_ARGS += -DUSER_C_MODULES=${USER_C_MODULES}
endif
change it to a:
ifdef USER_C_MODULES
CMAKE_ARGS += -DUSER_C_MODULES=$(abspath ${USER_C_MODULES})
endif
Thnx!
esp32: Integrate with the rp2 port mechanism to support user modules in cmake based builds.
This work started as new work to try and restore the User Module support to the ESP32 port. However now this work builds upon the rp2 port work which is working to upstreamed from their repository back into micropython master in pull request #6960.
Some of the work done here in py/usermod.cmake has been folded into #6960 so the changes in the most recent rebase are much simpler.
I've updated this initial message to better reflect the latest status of this pull request.
Using the latest changes you can build the firmware with user modules as follows:
$ cd ports/esp32
$ make USER_C_MODULES=/path/to/module/micropython.cmake