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."

Update: pthreads replaced with Asyncify

The rclpy/pthreads work described further down (CPython built with
--enable-wasm-pthreads, the vinca MODULE-vs-SHARED pthreads-flag fix)
has since been reverted. Real pthreads requires WebAssembly
--shared-memory, which is viral — every module that gets dlopen'd into
a host must also be pthreads/shared-memory, or linking fails. That's
exactly what blocked rclpy from loading inside a JupyterLite kernel
(xeus-python, built without pthreads upstream): rebuilding xeus/
xeus-python with pthreads to match got past the link error, but produced
a hard, total deadlock — xeus-python's own thread model can't tolerate a
blocking wait either.

Replaced with Asyncify: rmw_zenoh_pico's rmw_wait() now polls
zenoh-pico's own Z_FEATURE_MULTI_THREAD=0 single-threaded transport mode
(zp_read()/zp_send_keep_alive(), already used for e.g.
WITH_ARDUINO_OPENCR) in a loop that cooperatively yields via
emscripten_sleep(), instead of blocking a real OS thread on a
condition_variable. This removes the shared-memory requirement from the
whole closure — xeus/xeus-python never need to touch pthreads at all.

Also fixed along the way:

• rmw_zenoh_pico's own rmw_zenoh_pico_condition.h was missing a
  <pthread.h> include for pthread_condattr_t — the type is declared
  unconditionally by emscripten's libc regardless of -pthread, but
  zenoh-pico's own platform header only pulls it in under
  Z_FEATURE_MULTI_THREAD==1.
• rmw_zenoh_pico_set_unicast/set_mode/get_mode (used by consumers to
  override the compiled-in zenoh connect address at runtime) aren't part
  of the standard rmw.h ABI, so wasm-ld's side-module dead-code
  elimination dropped them from the export table — now explicitly exported
  via target_link_options(... "-Wl,--export=...").
• The two local patch/ros-rolling-rosidl-typesupport-microxrcedds-{c,cpp}.patch
  files mentioned below are gone — both are now fully subsumed by the
  Tobias-Fischer/rosidl_typesupport_microxrcedds fork pin (verified: both
  patches fail to apply against that fork's commit because it already
  contains every hunk they were adding).
• geometry_msgs/sensor_msgs added to the wasm32 closure.
• pixi.toml's build-emscripten is now a fixed two-pass sequence
  (build → mirror-sync → build again), replacing an open "loop until the
  package count stops changing" — nothing in this recipe set nests the
  native-mirror workaround more than one level deep, so two passes is
  provably sufficient, verified by clearing the mirror-dependent packages
  and confirming a full rebuild converges without a third pass.

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: builds rmw_zenoh_pico for
  wasm32 (see "Update" above for the Asyncify-specific hunks). The
  typesupport-backend codegen gap this PR originally patched locally
  (rosidl_typesupport_microxrcedds_{c,cpp}) is now fixed upstream instead
  — see "Upstream PRs" below — by pinning to a fork commit that already has
  it, so no local patch is needed for that package anymore.
• 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.
• The last blocker this surfaced: rosidl_typesupport_microxrcedds_cpp's
  codegen didn't handle ROS 2's auto-generated service/action "_Event"
  message, which used to mean rebuilding a dozen-plus affected packages by
  hand with different typesupport overrides after the main build (see the
  old revision of pixi.toml's build-emscripten comment in this PR's
  history for exactly how involved that was). Fixed at the source instead
  — see "Upstream PRs" below — so a single pixi run build-emscripten pass
  with both typesupport overrides set globally now builds the entire
  closure correctly. No more scoped rebuilds, and no more risk of silently
  routing a package through the wrong one (confirmed happened once, to
  type_description_interfaces, before this fix).

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, CMake export-set wiring, and missing Event message typesupport (C++) micro-ROS/rosidl_typesupport_microxrcedds#83 — ament_cmake_ros_core +
  export-set/BUILD_INTERFACE fixes, plus the missing Event-message
  typesupport codegen (see below)
• 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)
• fix: emscripten-wasm32 build fixes for RoboStack/ros-rolling (Asyncify, not real pthreads) 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

(Historical — the pthreads approach described in this section was reverted; see "Update" above. rclpy now runs without any custom pthreads-enabled CPython build at all, using the same Asyncify-based rmw_zenoh_pico as everything else.)

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.

One more narrow gap surfaced along the way, documented in this repo rather
than silently patched around:

• 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),
  in a single pixi run build-emscripten pass with both typesupport
  overrides set globally — no scoped per-package rebuilds.
• Every package that defines a service or action (action_msgs,
  rcl_interfaces, type_description_interfaces, test_msgs, ...)
  confirmed building with the correct typesupport backend actually
  wired into its dispatch table (checked via strings on the built
  .so).
• 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