std/target
The two axes a Vader build is parameterised by.
This module holds ONLY the vocabulary, because two very different things need to speak it and they live in different layers:
VADER_OS/VADER_ARCH: the COMPILATION target, baked at build time, and what@targetfilters on.current_os(): the OS the program is actually RUNNING on, answered at runtime by the C runtime.
They are not the same question: under --target=windows-x86_64 from a Mac the
two differ, and a program that manipulates its own environment (resolving a
path, spawning a process) wants the second. But they must share a type, or
current_os() == VADER_OS could not be written, and that comparison is
exactly what a cross-compiling toolchain asks. Sharing a type is why the
enums live here in std/ rather than a layer up: std/ may not import
toolchain/, and current_os() belongs to std/.
What is NOT here: Target, the pair, and the <os>-<arch> parsing the CLI
does. Those are compilation vocabulary: a program computing numbers has no
reason to parse "darwin-arm64", and they live in vader/support/target until a
build driver asks for them.
Types
Os :: enum(u8)An operating system a Vader program can be built for, or run on.
wasm is deliberately absent: it is an ARCHITECTURE, and the two systems
that run on it are far enough apart that one value would hide the difference
that matters: Wasi has a POSIX-shaped filesystem, Browser has none at
all. Code that selects on the OS needs to tell them apart.
Variants
Windows Linux Darwin Wasi Browser Arch :: enum(u8)An instruction set.
32-bit native targets are absent on purpose. The divergences they carry
(stdcall name decoration, WoW64 filesystem redirection) are specific to
32-bit Windows, and they are the only cases where the architecture would
have had to select CODE rather than parameterise values. Dropping them is
what lets @target filter on the OS alone.
Variants
X86_64 Arm64 Wasm32 Functions
current_os :: fn() -> OsThe operating system this process is RUNNING on.
Not the compilation target. VADER_OS answers that one, is baked at build
time, and is what @target selects on; the two differ whenever a build is
cross-compiled, and they differ for the compiler itself every time it emits
for a platform other than its own.
Use this one whenever the answer is about the environment the program finds
itself in: resolving a path, choosing a separator, deciding whether a binary
carries .exe. Using VADER_OS there is a bug that only shows up on a
cross-compiled build, which is the hardest kind to notice.
The runtime returns the variant's ordinal, so this enum's declaration order
is part of the contract with runtime/c/vader.h::vader_current_os: the same
coupling std/io::Stream already has with the write primitive.
Returns
Os the host OS, never null: an unsupported platform fails at C compile time rather than guessing.current_arch :: fn() -> ArchThe architecture this process is RUNNING on.
The runtime companion of current_os, and it carries the same warning:
VADER_ARCH is the architecture this build is FOR. They coincide for a
native binary and part company in the VM, in wasm, and in the C seed.
Returns
Arch the host architecture, never null: an unsupported one fails at C compile time rather than guessing.