Menuconfig transport selection does not propagate to vendored libmicroros build

Summary

Selecting Micro XRCE-DDS over UART under micro-ROS Settings > micro-ROS network interface select in idf.py menuconfig sets the ESP-IDF-side transport wrapper but has no effect on the vendored colcon build that produces libmicroros.a. The rmw layer is still compiled with -DRMW_UXRCE_TRANSPORT=udp from the vendored colcon.meta, so RMW_UXRCE_TRANSPORT_CUSTOM is never defined, rmw_microros/rmw_microros.h skips the guarded include of custom_transport.h, and any call to rmw_uros_set_custom_transport() fails at compile time with -Werror=implicit-function-declaration.

A workaround exists via app-colcon.meta at the app root, the pickup is already implemented in CMakeLists.txt and threaded through libmicroros.mk as APP_COLCON_META.

Environment

• Branch: jazzy
• Commit: 16cf0d534e618c2752e5546710cd2c81c0a586cc
• Target: ESP32-S3 DevKitC-1
• ESP-IDF: v5.3.5
• Host: Ubuntu 24.04 on WSL2

Reproducer

# From an ESP-IDF project with this component vendored under components/
idf.py set-target esp32s3
idf.py menuconfig
# Component config -> micro-ROS Settings -> micro-ROS network interface select -> "Micro XRCE-DDS over UART"
idf.py clean-microros
idf.py build

Application code calling rmw_uros_set_custom_transport() fails:

error: implicit declaration of function 'rmw_uros_set_custom_transport'
[-Werror=implicit-function-declaration]

The generated rmw_microxrcedds_c/config.h confirms the root cause:

#define RMW_UXRCE_TRANSPORT_UDP
/* #undef RMW_UXRCE_TRANSPORT_CUSTOM */

The menuconfig transport symbol CONFIG_MICRO_ROS_ESP_UART_TRANSPORT=y never enters the colcon build; the vendored colcon.meta hard-codes -DRMW_UXRCE_TRANSPORT=udp and this wins by default.

Verified workaround

Create app-colcon.meta at the app root (sibling to main/), using the required "names" wrapper:

{
    "names": {
        "rmw_microxrcedds": {
            "cmake-args": [
                "-DRMW_UXRCE_TRANSPORT=custom"
            ]
        }
    }
}

Then idf.py clean-microros && idf.py build. Verified end to end on the environment above: RMW_UXRCE_TRANSPORT_CUSTOM is defined in the built config.h and the application compiles and links cleanly.

Note: the "names" wrapper is required. A JSON body without it is parsed successfully, added to --metas, and its contents silently ignored, reproducing the original compile error with no signal that the override was rejected.

Proposed fix

Have the component's CMakeLists.txt map the Kconfig transport selection to the correct RMW_UXRCE_TRANSPORT value and generate a small meta file in the build tree, passed to colcon via the existing APP_COLCON_META seam. Any user-supplied app-colcon.meta continues to override the generated one, so nothing that already works breaks.

On the jazzy branch, Kconfig.projbuild exposes exactly three network-interface options, so the mapping is minimal:

• CONFIG_MICRO_ROS_ESP_NETIF_WLAN -> udp
• CONFIG_MICRO_ROS_ESP_NETIF_ENET -> udp
• CONFIG_MICRO_ROS_ESP_UART_TRANSPORT -> custom

Sketch (approve-or-steer level, not the final diff):

if(CONFIG_MICRO_ROS_ESP_UART_TRANSPORT)
    set(UROS_RMW_TRANSPORT "custom")
elseif(CONFIG_MICRO_ROS_ESP_NETIF_WLAN OR CONFIG_MICRO_ROS_ESP_NETIF_ENET)
    set(UROS_RMW_TRANSPORT "udp")
else()
    set(UROS_RMW_TRANSPORT "udp")
endif()

set(UROS_KCONFIG_META "${CMAKE_BINARY_DIR}/uros_kconfig_transport.meta")
file(WRITE ${UROS_KCONFIG_META}
"{\"names\": {\"rmw_microxrcedds\": {\"cmake-args\": [\"-DRMW_UXRCE_TRANSPORT=${UROS_RMW_TRANSPORT}\"]}}}\n"
)

# Compose APP_COLCON_META so user-supplied app-colcon.meta still wins
set(UROS_APP_COLCON_META "${UROS_KCONFIG_META}")
if(EXISTS "${PROJECT_DIR}/app-colcon.meta")
    set(UROS_APP_COLCON_META
        "${UROS_KCONFIG_META} ${PROJECT_DIR}/app-colcon.meta")
endif()

Users on WLAN or Ethernet: unchanged (both resolve to udp, matching the current vendored colcon.meta). Users with an existing app-colcon.meta: unchanged (their file is passed last and still wins). Users who edited the vendored colcon.meta directly: still works (their edit is the first --metas entry; the generated meta comes after and overrides only the transport field).

Cache invalidation

One rough edge worth flagging: changing the menuconfig transport option changes the content of the generated meta, but colcon's build cache for libmicroros.a is not invalidated on that change. An initial PR would preserve that behaviour and add a README note that idf.py clean-microros is required after any transport change. A follow-up PR could make the generated meta a proper build dependency of libmicroros.a for automatic invalidation; I would prefer to keep those separate.

Ask

I would like to submit this fix. Before writing the PR I want to confirm two things:

1. Is auto-generating the transport meta from Kconfig the direction you want? If you prefer a smaller change (README-only clarification of the app-colcon.meta workaround, its names schema requirement, and its silent-failure trap) I am happy to do that instead.
2. Is ${PROJECT_DIR}/app-colcon.meta the correct convention for the "app root" pickup on jazzy? That matches the existing CMakeLists.txt lines around 26-28; I want to confirm this generalises before I compose against it.

Diagnosis and workaround verified with ESP-IDF v5.3.5. Happy to attach a minimal reproducer as an example under examples/ if useful.

Thanks for maintaining this component.

Beginne mit den Transportoptionen in Kconfig.projbuild und der bestehenden APP_COLCON_META-Behandlung in CMakeLists.txt um die Zeilen 26–28 und verfolge anschließend, wie libmicroros.mk Metadaten an den vendorten colcon-Build übergibt. Reproduziere die UART-Konfiguration mit den aufgeführten idf.py-Befehlen und prüfe die generierte rmw_microxrcedds/config.h. Als erledigt gilt die Aufgabe, wenn der ausgewählte Transport die generierte Konfiguration erreicht und die Anwendung mit dem dokumentierten Bereinigungsschritt gebaut wird.