Add emscripten-wasm32 support with rmw_zenoh_pico

[Tobias-Fischer]

Summary

Adds emscripten-wasm32 as an opt-in target platform for rolling, using
rmw_zenoh_pico as the
RMW implementation. This follows the same emscripten-wasm32 port already
proven on humble (Tobias-Fischer/ros-humble, backed by
RoboStack/vinca#154), but
swaps the custom hand-rolled wasm_cpp/rmw_wasm_cpp RMW used there for
zenoh-pico, which has real, actively-maintained upstream WASM/pthreads
support — significantly less custom code to maintain.

All changes are gated by if: wasm32 / if: not wasm32 selectors (or
per-platform robostack.yaml dicts) and are additive — no behavior change
for existing platforms.

Verified end-to-end, both a C and a Python talker:

• A WebAssembly rclc talker node running in a real browser publishes
  std_msgs/String via rmw_zenoh_pico over a real WebSocket to a native
  zenohd router, received and correctly decoded by an independent native
  process.
• A real rclpy talker (CPython built with --enable-wasm-pthreads,
  including a real, non-stubbed numpy) running the same way in the same
  browser, also verified against a native subscriber.

Both are genuine cross-process interop, not just "doesn't crash."

What's included

• vinca.yaml / robostack.yaml / patch/dependencies.yaml /
  pkg_additional_info.yaml: thread the emscripten-wasm32 platform through
  the recipe pipeline (selectors, per-platform dependency-name mappings,
  rmw_implementation/typesupport wiring for the ~230-recipe closure).
• conda_build_config.yaml / vinca_pinning.yaml: emscripten toolchain pin
  (emscripten-forge's compiler/SDK) plus targeted pin overrides where
  emscripten-forge's package set diverges from conda-forge (python 3.13 vs
  3.14, graphviz/libffi versions) — base pins are preserved for every other
  platform.
• pixi.toml: points the vinca pypi dependency at
  RoboStack/vinca#154's branch
  until it merges upstream.
• patch/ros-rolling-*.patch: per-package emscripten build fixes (rclpy
  narrowing warning + -latomic link condition, rcutils, rosidl-generator-py,
  spdlog/yaml-cpp vendor policy, osrf-testing-tools-cpp,
  rmw_test_fixture_implementation).
• patch/ros-rolling-rmw-zenoh-pico.patch,
  patch/ros-rolling-rosidl-typesupport-microxrcedds-{c,cpp}.patch: build
  rmw_zenoh_pico and its typesupport backend for wasm32. The underlying
  fixes have been submitted upstream separately (see below); these patches
  apply them to the exact pinned commits until they merge.
• extra_recipes/zenoh-pico, extra_recipes/microcdr: new recipes for
  rmw_zenoh_pico's own dependencies, not otherwise packaged for RoboStack.

Upstream PRs

The genuine bugs found along the way (not RoboStack-specific) have been
submitted upstream rather than only patched here:

• fix(emscripten): usleep() instead of emscripten_sleep() for pthreads builds eclipse-zenoh/zenoh-pico#1314 — emscripten pthreads sleep fallback
• fix: emscripten (browser/WebAssembly) build and runtime support esol-community/rmw_zenoh_pico#7 — emscripten/browser support
• fix: ament_cmake_ros_core dependency and CMake export-set wiring for rolling micro-ROS/rosidl_typesupport_microxrcedds#83 — ament_cmake_ros_core +
  export-set/BUILD_INTERFACE fixes
• Add emscripten guards to shared_library.c's dlopen path ros2/rcutils#591 — emscripten guards for rcl_logging_implementation's
  dlopen-by-name backend selection (found getting rclpy's logging init
  working)
• Enable real pthreads for emscripten-wasm32 builds vinca#154 (updated) — also now sets
  CMAKE_SHARED_MODULE_CREATE_*_FLAGS, not just the SHARED-library
  variant. CMake's MODULE library type — what pybind11_add_module() uses
  for every Python C extension, including rclpy's own _rclpy_pybind11
  and each message package's rosidl_generator_py typesupport accessor —
  is distinct from SHARED and was linking without USE_PTHREADS=1. Never
  hit by the rclc/C-only path; only surfaced once a real rclpy demo
  linked a pybind11 module into the same pthreads build.

Getting rclpy running: what it actually took

Earlier revisions of this PR reported rclpy as blocked by CPython for
wasm32 not being pthread-enabled. That's fixed, and it turned out to be
one configure flag: CPython upstream has shipped --enable-wasm-pthreads
since 3.11 (adds exactly -pthread -sUSE_PTHREADS -sPROXY_TO_PTHREAD, the
same flags this whole pipeline already uses) — emscripten-forge's own
python recipe just doesn't turn it on. Building a custom variant with
that flag, plus registering numpy's ~14 eagerly-imported compiled
extension modules ahead of time (this build doesn't enable CPython's
--enable-wasm-dynamic-linking — its own docs flag that combination with
pthreads as known-crashy — so nothing can rely on Python's normal import
dynamically dlopen-ing a .so), got a real rclpy talker with real
numpy running end-to-end.

Two more narrow gaps surfaced along the way, both documented in this repo
rather than silently patched around:

• rosidl_typesupport_microxrcedds_cpp's codegen doesn't handle service
  "_Event" messages — specific to the C++ typesupport variant; the
  C variant those same packages (rcl_interfaces,
  type_description_interfaces, service_msgs) need for rmw_zenoh_pico
  builds fine. See the comment on pixi.toml's build-emscripten task.
• rmw_zenoh_pico doesn't support publisher/subscriber QoS event handlers
  (RCL_PUBLISHER_OFFERED_INCOMPATIBLE_QOS etc.) or TypeDescriptionService
  — the former fails with a plain RCLError instead of the
  UnsupportedEventTypeErrorrclpy already handles gracefully, and the
  latter hangs rather than erroring. Worked around locally for the demo
  (not upstreamed — didn't root-cause the rmw_zenoh_pico side tonight);
  worth a closer look if rclpy support here gets formalized further.

The rclpy demo itself (build script, patched rclpy/numpy, browser
harness) is local-only exploratory tooling, same as the existing rclc
one — not part of this PR's recipe changes.

Test plan

• Full recipe closure (~230 packages) builds green for
  emscripten-wasm32 + rmw_zenoh_pico.
• Browser demo: wasm32 rclc talker → real WebSocket → native zenohd →
  independent native subscriber, verified receiving correctly-decoded
  messages.
• Same, with a real rclpy talker (real numpy, not stubbed).
• Confirmed against a real (non-sandboxed) browser, not just automated
  tooling.

Full write-up

All the changes this required, across every repo, are documented together in Tobias-Fischer/ros2-emscripten-zenoh-demo — including a working rclcandrclpy browser demo verified end-to-end against a native zenohd router.

🤖 Generated with Claude Code