Runtimes — the alternative stdlib build

Active contributors: compnerd, etcwilde

Purpose

The top-level Runtimes/ directory is a newer, decoupled CMake build of the same standard library and overlays that live under stdlib/. The goal: a clean build that can be cross-compiled for any target without depending on the legacy host-toolchain assumptions baked into stdlib/CMakeLists.txt. Cross-compilers, SDK builders, and embedded toolchain producers consume this build.

The directory is described in Runtimes/Readme.md. Long-term it is intended to replace the in-tree stdlib/ build.

Directory layout

Runtimes/                                # 257 files
├── Core/                                # the Swift module + stdlib overlay
├── Overlay/                             # SDK overlays (Foundation, Dispatch, etc., when applicable)
├── Supplemental/                        # supplemental modules (Concurrency, Distributed, ...)
├── cmake/                               # shared CMake helpers
├── Resync.cmake                         # syncs sources from stdlib/
└── Readme.md

Sources are kept in sync with stdlib/ via the Resync.cmake script. Most contributors edit under stdlib/; the Runtimes/ build then picks up changes automatically when the resync runs.

How it differs from stdlib/

Aspect	stdlib/	Runtimes/
Build entry	Top-level CMakeLists.txt for the whole compiler	Standalone CMake project, can be invoked separately.
Cross-target	Bakes in swift-stdlib-tool / Apple-style multi-target	Treats each target as an independent configuration.
Toolchain	Uses the just-built swift-frontend	Uses an existing toolchain (the bootstrap compiler).
Configuration	Many implicit options	Explicit, opt-in per module.
Use cases	The "live" toolchain build everyone uses today	Cross-compile, SDK builders, embedded.

Why both exist

stdlib/ evolved organically since 2010 with many platform-specific assumptions (Mach-O segment names, dyld behavior, Apple-specific resilience boundaries). Replacing it directly was risky. Instead, Runtimes/ was added as a parallel build that pulls in the same sources but reorganizes the configuration. As Runtimes/ reaches feature parity, it will become the default build.

Use cases

• Cross-compilation toolchains that ship a Swift toolchain for embedded or Linux targets.
• Static libstdcpp style builds for FreeBSD, OpenBSD, Wasm.
• Embedded -- the embedded build is much easier to express in Runtimes/ than in the legacy stdlib/.
• Custom platforms -- new ports (e.g., a hypothetical RTOS) start by adding to Runtimes/ rather than untangling stdlib/CMakeLists.txt.

Integration points

• utils/build-script can drive Runtimes/ for select targets.
• The Swift Toolchains for Linux continue to use stdlib/ for now; this is expected to flip eventually.
• Embedded Swift uses Runtimes/ for several of its supported targets.

Entry points for modification

• Adding a new platform: see Runtimes/cmake/ for shared helpers and existing platform examples.
• Adjusting the resync rules: Runtimes/Resync.cmake.
• Most stdlib changes still belong under stdlib/ and will flow into Runtimes/ automatically.

Related pages

• Standard library -- the source of truth.
• Embedded Swift -- a major consumer of Runtimes/.