Rust Build System Architecture
Relevant Rust source files
Cargo.tomlrust-toolchain.tomlMakefilecrates/Cargo.tomlcrates/adapters/databento/Cargo.tomlcrates/adapters/interactive_brokers/Cargo.toml
The root Cargo workspace is the build authority. It pins edition 2024, Rust 1.97.0 at this revision, workspace package metadata, shared internal crate versions, and third-party dependencies. Resolver version 2 prevents unrelated target features from being unified as aggressively as the legacy resolver.
Crate graph
Foundation crates (core, model, common) sit below engine crates (data, risk, execution, portfolio, trading, system). backtest and live compose execution contexts. Persistence, infrastructure, serialization, network, event-store, CLI, and plugin crates supply bounded capabilities. Provider adapters depend inward on those contracts.
Internal dependencies should normally use { workspace = true } in member manifests. That keeps one version and feature policy visible at the root and prevents a member crate from silently selecting an incompatible internal release.
Features
Important feature families include high precision, live runtime support, persistence/streaming codecs, database backends, and optional bindings. Adapter manifests often disable default features for internal workspace use so the root can control high precision explicitly. Consumers should inspect each selected crate rather than assuming workspace defaults are appropriate.
nautilus-databento exposes historical and live modules through features. nautilus-interactive-brokers currently has its own data/execution/example feature arrangement and is not published at the pinned revision. Treat that difference as a distribution constraint, not an API equivalence.
Profiles and reproducibility
Debug builds optimize iteration and assertions; release builds optimize runtime behavior. Bench profiles and target-specific settings belong in Cargo configuration rather than ad hoc local flags. The pinned toolchain, lockfile, root dependency table, and CI scripts together form the reproducible build contract.
Run the smallest crate build during iteration, but validate the feature combinations actually shipped. A default-feature build cannot prove a default-features = false consumer, high-precision mode, Windows compatibility, or an adapter example.