ESP32 micropython port build with relative path to external user C-modules was failed

[aso-c]

Checks

• [X] I agree to follow the MicroPython Code of Conduct to ensure a safe and respectful space for everyone.

• [X] 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!

[kdschlosser]

I believe you need an additional set of ..'s on the path.

so it would be ../../../examples/usercmodule/micropython.cmake

The reason why this occurs is because of how micropython gets added to the IDF build as a component so the starting path for the build is actually ports/esp32/main_* it's 3 levels up not 2.

[YanKE01]

You can try to compile using absolute paths.

[kdschlosser]

I do all the time and it works without any issue.

[kdschlosser]

absolute or relative both work the same.

[andrewleech]

I tend to use absolute paths myself. I'm not sure if it's still a problem for all ports, but I've had situations where relative paths are used to point to cmodule and result in the built .o files end up similarly relative (ie outside) the build folder :-) I'm pretty sure when they happened to me it was on a make based port like Unix or stm32, don't know if it would affect cmake ports as well.

The main other trap with relative paths is it's not obvious where it needs to be relative to as @kdschlosser said, on other ports it's often the port folder being built, or it sounds like for esp32 one folder further in, which is often not the folder you're running make from. It can take trial and error to make it work basically.

[kdschlosser]

I too have had things end up outside the build folder and I believe that is the result of using relative includes in the source files and not actually a result of the actual path to the user_c_module.

When dealing with a 100% make build the path needs to point to the parent folder of the folder where the makefile resides. The makefile builds does a recursive check down the entire tree for makefiles that are named "micropython.mk". with cmake builds you have to point the path to an actual cmake file and you need to add an additional ../ to the start of the path if using a relative path. It is just easier to use absolute paths and not have to worry about it working.