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` / `-isystem` / `-c` / `-o`, `-MD -MF`
14//! depfiles).
15//! - [`Dialect::Msvc`] — the Microsoft `cl.exe` / `lib.exe` driver
16//! (`/std:c++17`, `/O2`, `/D` / `/I` / `/external:I` / `/c` /
17//! `/Fo`, `/showIncludes` dependency tracking).
18//!
19//! The dialect owns every platform- and toolchain-specific
20//! decision: how artifacts are named ([`Dialect::object_extension`],
21//! [`Dialect::static_library_name`], [`Dialect::executable_name`]),
22//! how Ninja discovers header dependencies ([`Dialect::ninja_deps`]),
23//! and how each [`BuildAction`] is spelled ([`lower()`]). The planner
24//! and the Ninja writer stay dialect-agnostic: they ask the dialect.
25//!
26//! This split mirrors the way LLVM's `clang` Driver constructs
27//! per-toolchain jobs and the way `rustc` selects a `LinkerFlavor`:
28//! one abstract description, many concrete spellings. Everything
29//! here is pure, deterministic, and free of I/O, so both dialects
30//! are fully unit-testable on any host.
31
32pub mod action;
33pub mod dialect;
34pub mod lower;
35
36pub use action::{
37 ArchiveAction, BuildAction, CompileAction, CompileArguments, CompileMode, LinkAction,
38};
39pub use dialect::{Dialect, NinjaDeps};
40pub use lower::{LoweredAction, LoweredActionKind, compile_argv, lower};