Macro force_link_backend 

macro_rules! force_link_backend {
    ($backend:ident) => { ... };
}

Define Zephyr’s rust_main for a self-bringup Rust component package.

The macro is intended for rust_cargo_application() apps whose crate already invokes nros::node!(). It opens a Zephyr executor, registers the supplied component through ExecutorNodeRuntime, and spins forever. Issue 0330 — force-link an RMW backend crate into a pure-Rust staticlib.

On a Rust-only image (Zephyr and friends) the Zephyr module emits a weak nros_rmw_<name>_register and calls it only if it resolves. The strong definition is the backend crate’s #[no_mangle] export — and rustc’s staticlib DCE drops it unless something in the crate being compiled into the staticlib references that crate. The symbol is then present in the rlib and absent from the .a, the weak call sees NULL, and the image comes up with no backend registered (issues 0155 / 0163).

This emits the reference, without naming any backend in nano-ros’ own RMW-agnostic layers — the app crate names it, because the app crate is what selects an RMW:

#[cfg(feature = "rmw-zenoh")]
nros::force_link_backend!(nros_rmw_zenoh);
#[cfg(feature = "rmw-xrce")]
nros::force_link_backend!(nros_rmw_xrce_cffi);

It is an ANCHOR, not a registration call — the static is never executed (same class as nros-c’s FORCE_LINK and nros-rmw-cffi’s section anchor). Registration happens through nros_app_register_backends. Backends whose register entry lives in a C/C++ library the image already links (cyclonedds on Zephyr) need no anchor at all.

Invoke at module scope. Multiple invocations in one crate are fine — each expands inside its own anonymous const, so the static names cannot collide.