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.

Making this genuinely buildable from a clean checkout

Earlier revisions of this PR had only been exercised incrementally, on a
local output/ directory that had accumulated a lot of by-hand state. Since
then it's been rebuilt from a genuinely empty output/ directory (twice, to
also re-verify the vinca ordering fix below), which surfaced several real
bugs a from-scratch build hits that an incremental one never does:

• patch/dependencies.yaml: rosidl_typesupport_c/rosidl_typesupport_cpp
  now declare a real add_host dependency on
  ros2-rosidl-typesupport-microxrcedds-{c,cpp} (and likewise test_msgs/
  example_interfaces, needed for the same reason as the packages already
  listed on pixi.toml's build-emscripten comment below). Without this,
  rattler-build's solver has no declared reason to build the microxrcedds
  typesupport packages before the packages that find_package() them, so a
  from-scratch build's ordering came down to luck — sometimes it built in
  the right order, sometimes a plain find_package() failed outright. This
  replaced an earlier, hacky retry-loop workaround with the actual missing
  dependency declaration, so rattler-build now builds the correct order
  itself, every time.
• extra_recipes/{microcdr,zenoh-pico}/build.sh: these existed only on a
  local machine, never actually committed — silently swallowed by a blanket
  *.sh .gitignore rule (now negated for extra_recipes/**/*.sh). Any
  genuinely fresh checkout failed with "build.sh: command not found".
• pixi.toml's new sync-native-bootstrap-mirror task (wired into
  build-emscripten's depends-on) scripts a workaround that used to be
  manual, undocumented tribal knowledge: several message packages' generated
  recipes declare a build:-time (build-platform, i.e. native osx-arm64)
  dependency on rosidl_default_generators, but no channel publishes a
  native ros2-*-prefixed build of anything — it's permanently
  unsatisfiable as declared. CMake's own find_package() resolution only
  ever needed the host-prefix (emscripten-wasm32) copy (already
  cross-compilation-safe via -DCMAKE_FIND_ROOT_PATH=$PREFIX); rattler-build's
  solver is what insists on a real build-platform channel entry. Mirroring
  already-built emscripten-wasm32 packages into a same-named osx-arm64
  channel directory and reindexing satisfies the solver without any actual
  native rebuilding.
• pixi.toml's vinca pin is now on
  Tobias-Fischer/vinca@c974b23
  (part of RoboStack/vinca#154),
  which fixes a genuine CMake target-registration-ordering bug found while
  re-verifying this PR from scratch — see that PR's description for the
  full root-cause writeup. In short: pre-finding the static typesupport
  override for a message-generating package (rather than only for
  consumers, which is what it's actually for) made that package's own
  typesupport target jump ahead of the generator target its own
  Export.cmake requires, breaking every downstream find_package() of it.
  First surfaced here on builtin_interfaces, breaking service_msgs.

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
  UnsupportedEventTypeError rclpy 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, from a genuinely empty
  output/ directory (not incrementally on top of prior local state).
• Browser demo: wasm32 rclc talker → real WebSocket → native zenohd →
  independent native subscriber, verified receiving correctly-decoded
  messages via the router's own REST API (not just the browser's own
  console).
• Same, with a real rclpy talker (real numpy, not stubbed), also
  independently confirmed via the router's REST API.
• 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 rclc and rclpy browser demo verified end-to-end against a native zenohd router.

🤖 Generated with Claude Code