ESP32/modules has symlinks outside of the repository

[rmahna2]

Currently in order to have all the symlinks files in ports/esp/modules available for the ESP32 build a micropython/micropython-lib repository needs to be located at the same directory level as the micropython/micropython-esp32 repository.

The ESP32/README.MD should include this detail unless there's something that can be done to change the characteristic.

There are two symlinks with this problem.
micropython-esp32/ports/esp32/modules/upysh.py
symlinks to "../../../../micropython-lib/upysh/upysh.py"

micropython-esp32/ports/esp32/modules/urequests.py
symlinks to "../../../../micropython-lib/urequests/urequests.py"

[nickzoic]

Yeah, I'm not a fan of the symlinks in general. They're also problematic for people trying to build under Windows and the broken ones (which you point out) are ugly.

@dpgeorge and I diiscussed them at PyConAU and I think we were kicking around the idea of replacing them with explicit Makefile targets, so ports/esp32/Makefile would have a target like:

FROZEN_MODULES = modules/*.py ../../tools/upip.py ../esp8266/modules/onewire.py

(etc) that way you're explicitly listing what you want rather than letting symlinks do it for you.

[MrSurly]

Why isn't micropython-lib just a git submodule? Let the Makefile warn you if the submodule isn't init'd.

Maybe a make config or make menuconfig is in order?

[dpgeorge]

This is a general problem of the repo to address upstream.