Kapitel 02: Einrichtung & Erstes Programm (Sicht für Profis)

Dieses Kapitel behandelt die Cargo-Build-Infrastruktur, Dependency-Management, semantische Versionierung und die Trennung von Entwicklungs- und Produktionsprofilen.

1. Lernziele

In diesem Abschnitt werden Sie:

Verstehen, wie Cargo reproduzierbare Builds über Lockfiles erzwingt.
Die Funktionsweise der semantischen Versionierung (SemVer) bei Cargo analysieren.
Die Konfiguration von Build-Profilen in der Cargo.toml beherrschen.
Die Strukturierung von Cargo-Workspaces kennenlernen.

2. Item 2: Nutze Cargo zur Gewährleistung reproduzierbarer Builds

In der professionellen Entwicklung ist es kritisch, dass ein Programm auf dem Rechner des Entwicklers, auf dem CI-Server und in der Produktionsumgebung exakt gleich gebaut wird. Cargo stellt dies durch zwei Dateien sicher:

Cargo.toml (Deklarative Konfiguration): Hier spezifiziert der Entwickler die direkten Abhängigkeiten und deren Versionsbereiche (z. B. rand = "0.8.5").
Cargo.lock (Konkreter Zustands-Pin): Diese Datei wird von Cargo automatisch generiert. Sie enthält die exakten Versionsnummern und kryptografischen Hashes aller installierten Abhängigkeiten und deren Unterabhängigkeiten.

graph LR
    A[Cargo.toml] --> B(Cargo Build)
    B --> C[Cargo.lock generieren/lesen]
    C --> D[Kryptografischer Abgleich der Crates]
    D --> E[Reproduzierbares Binär-Artefakt]

Important

Check-in-Regel: Checken Sie die Cargo.lock bei eigenständigen Anwendungen (Binaries) immer in Ihre Versionsverwaltung (Git) ein. Bei Bibliotheken (Libraries) wird die Cargo.lock traditionell ignoriert (.gitignore), da die Bibliothek flexibel mit den Versionen des Nutzers kompatibel sein muss.

3. Semantische Versionierung (SemVer) in Cargo

Cargo verwendet die semantische Versionierung (Major.Minor.Patch). Standardmäßig nutzt Cargo das Caret-Symbol (^) als Standard-Operator:

rand = "0.8.5" entspricht ^0.8.5 und erlaubt Updates auf 0.8.6 oder 0.8.9, blockiert aber 0.9.0.
Bei Versionen vor 1.0.0 (Pre-1.0) gilt eine Besonderheit: 0.8.5 erlaubt keine Updates auf 0.9.0, da Minor-Versionen vor 1.0 als Major-Updates (mit brechenden API-Änderungen) behandelt werden.

4. Build-Profile (Debug vs. Release)

Cargo unterscheidet grundlegend zwischen Entwicklungs- und Produktions-Builds. Dies wird über Profile in der Cargo.toml gesteuert:

[profile.dev]
opt-level = 0      # Keine Optimierungen, schneller Compile-Vorgang
debug = true       # Debug-Symbole im Binär-Artefakt enthalten

[profile.release]
opt-level = 3      # Maximale Optimierungen (Inlining, Loop Unrolling)
lto = true         # Link-Time Optimization über Crate-Grenzen hinweg
codegen-units = 1  # Reduziert Parallelisierung beim Kompilieren für bessere Optimierung

cargo build erzeugt ein unoptimiertes Artefakt in target/debug/.
cargo build --release erzeugt das hochoptimierte Produktions-Artefakt in target/release/.

5. Cargo-Workspaces für Multi-Crate-Architekturen

Bei größeren Projekten empfiehlt es sich, das System in mehrere eigenständige Crates aufzuteilen. Ein Cargo-Workspace ermöglicht die gemeinsame Nutzung eines einzigen target/-Ordners und einer globalen Cargo.lock:

# Haupt-Cargo.toml im Root-Verzeichnis
[workspace]
members = [
    "crates/cli",
    "crates/core",
    "crates/parser"
]

6. Key Takeaways (Architektur-Richtlinien)

Lockfiles: Committen Sie die Cargo.lock bei Binaries, um deterministische CI/CD-Pipelines zu sichern.
Profile Tuning: Optimieren Sie das release-Profil durch Aktivierung von LTO (Link-Time Optimization) in performance-kritischen Anwendungen.
Modularität: Strukturieren Sie wachsende Codebasen frühzeitig als Cargo-Workspaces.

Keyboard shortcuts