userspace.party

userspace.party / userspace_build

userspace_build

Build the machinery.

Host/build-side support needed to construct the freestanding runtime without smuggling build concerns into runtime crates.

API docs crates.io GitHub
build-time tooling with_std freestanding

Its place in the system

userspace_build exists to keep construction-time responsibilities separate from runtime responsibilities while remaining versioned with the same system.

source crates
     ↓
userspace_build
     ↓
link / construct / generate
     ↓
freestanding artifacts

The boundary

Belongs here

  • Build scripts and host-side construction support
  • Generation/link integration needed before runtime
  • Build-only use of std when intentional

Does not belong here

  • Runtime syscall semantics
  • Generic domain-independent containers
  • Browser UI
  • Physical-system models

Today

Current surface

  • Build-side target/file/memory machinery
  • with_std and no_std feature modes
  • Build-dependency integration for freestanding members
  • Shared release line with the ecosystem

Start here

[build-dependencies]
userspace_build = { version = "0.2", features = ["with_std"] }

The long-term rule is simple: construction-time concerns belong here; runtime concerns belong in the runtime crate.

From abstraction to reality. userspace.party keeps conceptual borders explicit: abstractions in ample, process mechanisms in userspace, machines in computers, human meaning in humans, browser presentation in webspace, and physical-world simulation and control in twins.