py/usermod: Route usermod sources through native port build.

[andrewleech]

Summary

User C module sources on cmake-based ports are compiled via INTERFACE library linking rather than through the port's native source registration. This means usermod sources miss platform compile flags that are applied at the directory or component level. On ESP32, user C modules are compiled without optimisation flags across all architectures because ESP-IDF applies flags via add_compile_options() during idf_component_register(), which doesn't propagate to INTERFACE library sources. On rp2 it works by accident because CMAKE_BUILD_TYPE=MinSizeRel sets flags via the truly global CMAKE_C_FLAGS.

This adds MICROPY_SOURCE_USERMOD (the flat source list already gathered by usermod_gather_sources()) to each port's native source registration — idf_component_register(SRCS) on esp32 and target_sources() on rp2 — the same way every other source domain (py, extmod, shared, lib, drivers, port, board) already works. INTERFACE_SOURCES are cleared from usermod targets after gathering to prevent double compilation. The existing target_link_libraries(${MICROPY_TARGET} usermod) is kept for propagating non-source INTERFACE properties (compile definitions, compile options, link libraries).

No user-facing API change. Existing micropython.cmake module files work as-is.

This is the root cause of several existing issues:

• Fixes cmake: Route usermod sources through native port build systems. micropython/micropython#18880 — optimisation flags now propagate to user C modules on ESP32.
• Fixes User C module fails to link in esp32 port micropython/micropython#16284 — double compilation is prevented by clearing INTERFACE_SOURCES after gathering into the flat list.
• Partially addresses Discussion #13538 — per-module target_compile_definitions(... INTERFACE ...) now reach usermod sources because they compile as part of the main target which links the INTERFACE library.
• Does not fix ESP32: "user C modules" should be able to add components to the build micropython/micropython#8041 — that issue requires IDF component dependency registration during CMAKE_BUILD_EARLY_EXPANSION, which is a separate mechanism from source compilation.

Testing

Built ESP32_GENERIC (IDF v5.5.1) and RPI_PICO with USER_C_MODULES pointing to examples/usercmodule/micropython.cmake. Verified from build logs:

• ESP32 usermod sources compile with -O2, matching core sources. Previously they had no optimisation flag.
• Each usermod source appears exactly once in the build — no double compilation on either port.
• Build without USER_C_MODULES also succeeds (empty MICROPY_SOURCE_USERMOD is harmless).

Not tested: zephyr port (doesn't currently support user C modules).

Trade-offs and Alternatives

usermod_gather_sources() is now a destructive operation — it clears INTERFACE_SOURCES from each target as a side effect, making it non-idempotent. This is acceptable because it's called exactly once (line 63 of py/usermod.cmake) and the alternative of conditionally skipping the INTERFACE link or adding per-port source deduplication would be more invasive.

An alternative would be to inject platform flags into the usermod INTERFACE library (e.g. idf_build_get_property + target_compile_options(usermod INTERFACE ...)), but that's a workaround rather than fixing the architectural mismatch.

Generative AI

I used generative AI tools when creating this PR, but a human has checked the code and is responsible for the description above.