Expand description
Issue 1763 — the same env rung for a #![no_std] image inside a host
process (threadx-linux, freertos-posix), read with the C library’s getenv.
target_os = "linux" is “a C library is linked” on this tree. Compiled on
every Linux build, not only not(feature = "env") ones: feature
unification can turn nros/env on under a caller whose own env is off,
and the caller must still find this. Where a caller has env, it uses the
std::env reader instead (nros-c/nros-cpp resolve_boot).
Issue 1763 — the boot-config ENV rung for a #![no_std] image that still
runs inside a host process, read through the C library’s getenv.
crate::env reads the same variables through std::env, so it needs
std. Until issue 1763 every image that had an environment also had std,
so that was one fact. It stopped being one when the host simulators dropped
libstd: threadx-linux’s C/C++ runtime staticlib (issue 1763) and
freertos-posix’s (issue 1778) are alloc, but they are still Linux
processes with a C library and an environment. Without this module those
images silently stopped honouring $ROS_DOMAIN_ID and $NROS_LOCATOR.
That was measured on freertos-posix: the C and C++ cells, run in parallel
with distinct domains, both fell back to the baked domain and heard each
other, so the C++ listener printed a Received: before its own talker
published.
The variables, their precedence and their errors are the SAME as
crate::env’s. Only the reader differs. Issue 0687’s rule still holds:
the edge that has an environment reads it, and the core takes values. The
edge is “a C library is linked”, which on this tree is target_os = "linux". A cross target has no getenv to call, and this module does not
exist there.
Strings are borrowed from the process environment, which outlives the boot.
Nothing in nano-ros calls setenv after boot, and the std reader made the
same assumption by caching its first read.
Functions§
- try_
resolve_ hosted ExecutorConfig::try_resolve_withwith thegetenvrung — the#![no_std]hosted twin ofcrate::env::try_resolve_hosted.