Any cmods CMake build that is not an esp32 build now fails at generate time, and the module that fails is not the one being built.
Reproduced today while verifying an unrelated audioif change (audioif#18):
cd /home/brad/gh/pydevices/cmods && ./build_mp.sh --port rp2 --board RPI_PICO2
CMake Error at /home/brad/gh/pydevices/cmods/cameraif/micropython.cmake:25 (target_link_libraries):
The link interface of target "usermod_cameraif" contains:
idf::esp_driver_cam
but the target was not found.
Call Stack (most recent call first):
/home/brad/gh/pydevices/cmods/micropython.cmake:14 (include)
/home/brad/gh/pydevices/cmods/micropython/py/usermod.cmake:56 (include)
CMakeLists.txt:97 (include)
make: *** [Makefile:80: submodules] Error 1
I confirmed it is not caused by the change I was testing: the same build fails identically with that change removed from the working tree.
The cause is straightforward. micropython.cmake:24-30 links four ESP-IDF component targets unconditionally:
target_link_libraries(usermod_cameraif INTERFACE
idf::esp_driver_cam
idf::esp_driver_isp
idf::esp_driver_jpeg
idf::esp_driver_ppa
)Those targets exist only inside an ESP-IDF build. The workspace aggregator (cmods/micropython.cmake) includes every module's micropython.cmake for every CMake port, so rp2 — and any other non-IDF CMake port — picks this file up and dies on it. esp32 ESP32_GENERIC_P4 builds fine (I ran it in the same session), which is exactly why nobody noticed: this is the "the port a module is least for is the one nobody builds first" shape from docs/agent-knowledge/workspace-craft.md, same as usbif's UVC link break in September.
The fix is presumably the same guard the other esp32-only modules use — something on the order of if(ESP_PLATFORM) or if(TARGET idf::esp_driver_cam) around both the sources and the link line, so the module contributes nothing on ports it cannot serve. I have not made that change; cameraif is not my deck and the guard should be chosen by whoever knows which ports the module intends to claim.
Impact while it stands: nobody can build rp2 through build_mp.sh, and the shared-aggregator cross-port check that catches breaks like this one for every other module in cmods is itself unavailable on rp2.
Any
cmodsCMake build that is not an esp32 build now fails at generate time, and the module that fails is not the one being built.Reproduced today while verifying an unrelated audioif change (audioif#18):
I confirmed it is not caused by the change I was testing: the same build fails identically with that change removed from the working tree.
The cause is straightforward.
micropython.cmake:24-30links four ESP-IDF component targets unconditionally:Those targets exist only inside an ESP-IDF build. The workspace aggregator (
cmods/micropython.cmake) includes every module'smicropython.cmakefor every CMake port, so rp2 — and any other non-IDF CMake port — picks this file up and dies on it.esp32 ESP32_GENERIC_P4builds fine (I ran it in the same session), which is exactly why nobody noticed: this is the "the port a module is least for is the one nobody builds first" shape fromdocs/agent-knowledge/workspace-craft.md, same as usbif's UVC link break in September.The fix is presumably the same guard the other esp32-only modules use — something on the order of
if(ESP_PLATFORM)orif(TARGET idf::esp_driver_cam)around both the sources and the link line, so the module contributes nothing on ports it cannot serve. I have not made that change; cameraif is not my deck and the guard should be chosen by whoever knows which ports the module intends to claim.Impact while it stands: nobody can build rp2 through
build_mp.sh, and the shared-aggregator cross-port check that catches breaks like this one for every other module in cmods is itself unavailable on rp2.