cabin_driver/lib.rs
1//! Compiler-dialect drivers for Cabin's build backend.
2//!
3//! Cabin's planner ([`cabin_build`](../cabin_build/index.html))
4//! produces a *toolchain-independent* semantic IR — a list of
5//! [`BuildAction`]s describing what to compile, archive, and link,
6//! with no compiler flags spelled out. This crate is the single
7//! boundary where that intent becomes a concrete command line.
8//!
9//! A [`Dialect`] names a compiler command-line family. Two are
10//! supported:
11//!
12//! - [`Dialect::GnuLike`] — the GCC / Clang driver (`-std=c++17`,
13//! `-O2`, `-D` / `-I` / `-c` / `-o`, `-MMD -MF` depfiles).
14//! - [`Dialect::Msvc`] — the Microsoft `cl.exe` / `lib.exe` driver
15//! (`/std:c++17`, `/O2`, `/D` / `/I` / `/c` / `/Fo`,
16//! `/showIncludes` dependency tracking).
17//!
18//! The dialect owns every platform- and toolchain-specific
19//! decision: how artifacts are named ([`Dialect::object_extension`],
20//! [`Dialect::static_library_name`], [`Dialect::executable_name`]),
21//! how Ninja discovers header dependencies ([`Dialect::ninja_deps`]),
22//! and how each [`BuildAction`] is spelled ([`lower()`]). The planner
23//! and the Ninja writer stay dialect-agnostic: they ask the dialect.
24//!
25//! This split mirrors the way LLVM's `clang` Driver constructs
26//! per-toolchain jobs and the way `rustc` selects a `LinkerFlavor`:
27//! one abstract description, many concrete spellings. Everything
28//! here is pure, deterministic, and free of I/O, so both dialects
29//! are fully unit-testable on any host.
30
31pub mod action;
32pub mod dialect;
33pub mod lower;
34
35pub use action::{
36 ArchiveAction, BuildAction, CompileAction, CompileArguments, CompileMode, LinkAction,
37};
38pub use dialect::{Dialect, NinjaDeps};
39pub use lower::{LoweredAction, LoweredActionKind, compile_argv, lower};