Modul 16 — Cargo für Fortgeschrittene: Profile, Workspaces & Veröffentlichen
Release-Profile, eigene Build-Konfiguration, Workspaces für Monorepos, Dokumentation und das Veröffentlichen auf crates.io. Lerne, Cargo über build & run hinaus zu nutzen.
Release-Profile & Optimierung
Lektion 67 von 7
Profile steuern Optimierung
Cargo hat zwei Standard-Profile:
- dev: für Entwicklung — schnell kompiliert, wenig optimiert
- release: für Auslieferung — langsam kompiliert, stark optimiert
cargo build nutzt dev, cargo build --release nutzt release. In deiner
Cargo.toml kannst du Profile anpassen:
[profile.dev]
opt-level = 0 # keine Optimierung, schnell bauen
[profile.release]
opt-level = 3 # maximale Optimierung
opt-level reicht von 0 (schnell bauen, langsam laufen) bis 3 (langsam bauen,
schnell laufen).
dev vs. release — ein bewusster Trade-off
Die Profile tauschen Compile-Zeit gegen Laufzeit-Performance. Während
der Entwicklung willst du schnelle Builds (dev, opt-level = 0). Beim
Ausliefern willst du schnelle Programme (release, opt-level = 3). Der
Compiler-Optimierer macht aus demselben Code sehr unterschiedlich schnelle
Programme.
Praxis-Szenario: Der langsame Export
Der Batch-Export braucht in Prod 40 Minuten, lokal vier. Ein Kollege optimiert seit Tagen den Code — ohne Erfolg. Die Build-Logs zeigen: Prod läuft mit der Debug-Binary.
Übung: Release-Profile erkennen
🧩 Übung m16-l67-e1
🔮 Vorhersage: Was passiert beim Ausführen?
✅ Wichtige Erkenntnisse
Haken setzen, um deinen Lernfortschritt zu markieren:
Eigene Profile & Optimierungs-Feinheiten
Lektion 68 von 7
Profile gezielt anpassen
Du kannst für jedes Profil einzeln festlegen:
[profile.release]
opt-level = 3
debug = false # keine Debug-Infos
lto = true # Link-Time-Optimization
codegen-units = 1 # mehr Optimierung, langsamerer Build
lto = true— optimiert über Modulgrenzen hinweg (langsamer Link)codegen-units = 1— eine Codegen-Einheit → bessere Optimierungpanic = "abort"— kleineres Binary, aber kein unwinding
Feintuning bewusst einsetzen
Standardwerte sind für die meisten Fälle gut. opt-level = 3, lto = true
und codegen-units = 1 bringen für Bibliotheken mit vielen kleinen Funktionen
oft spürbare Gewinne — aber auf Kosten längerer Builds.
Optimierung messen, nicht raten
Bevor du Profile aufdrehst, miss: cargo build --release und Benchmark
deines echten Workloads. Viele Optimierungs-Flags haben Trade-offs (mehr Binary
Größe, langsamere Builds). Nur optimieren, was nachweislich ein Engpass ist —
die ponytail:-Regel gilt auch hier.
✅ Wichtige Erkenntnisse
Haken setzen, um deinen Lernfortschritt zu markieren:
Workspaces: mehrere Crates verwalten
Lektion 69 von 7
Ein Workspace bündelt Crates
Ein Workspace ist eine Gruppe von Crates, die sich ein Cargo.lock- und
target/-Verzeichnis teilen. Ideal für Monorepos oder Libraries mit mehreren
Teilen:
workspace/
├── Cargo.toml # Workspace-Root
├── adder/
│ ├── Cargo.toml
│ └── src/lib.rs
└── add_one/
├── Cargo.toml
└── src/lib.rs
In der Root-Cargo.toml:
[workspace]
members = ["adder", "add_one"]
Vorteile
- Ein gemeinsames
Cargo.lock→ konsistente Abhängigkeiten - Ein
cargo buildbaut alle Mitglieder - Crates können sich gegenseitig mit Pfad-Abhängigkeiten nutzen
# adder/Cargo.toml
[dependencies]
add_one = { path = "../add_one" }
Workspace = geteilte Infrastruktur
Alle Mitglieder teilen sich target/ (Build-Artifakte) und Cargo.lock
(Versionen). Das spart Speicher und hält die Abhängigkeiten konsistent — jede
Crate im Workspace nutzt exakt dieselben Versionen.
Übung: Doc-Test reparieren
🧩 Übung m16-l69-e1
🔮 Vorhersage: Was passiert beim Ausführen?
✅ Wichtige Erkenntnisse
Haken setzen, um deinen Lernfortschritt zu markieren:
Dokumentation: doc-Kommentare
Lektion 70 von 7
/// für öffentliche Doku
Mit ///-Kommentaren dokumentierst du Items. cargo doc baut daraus eine
HTML-Dokumentation:
/// Addiert zwei Zahlen.
///
/// # Beispiele
///
/// ```
/// let ergebnis = addiere(2, 3);
/// assert_eq!(ergebnis, 5);
/// ```
pub fn addiere(a: i32, b: i32) -> i32 {
a + b
}
Die Code-Blöcke im ///-Kommentar werden bei cargo test als Doc-Tests
ausgeführt — Dokumentation, die sich selbst prüft.
//! dokumentiert die Crate
//!-Kommentare (am Dateianfang) dokumentieren die gesamte Crate oder das
Modul, nicht ein einzelnes Item.
Doc-Tests halten Beispiele aktuell
Code-Beispiele in ///-Kommentaren laufen bei cargo test mit. Verhält sich
dein Code anders als dokumentiert, schlägt der Doc-Test fehl. So verhindert
Rust, dass deine Doku veraltet — ein mächtiges Werkzeug.
✅ Wichtige Erkenntnisse
Haken setzen, um deinen Lernfortschritt zu markieren:
Veröffentlichen auf crates.io
Lektion 71 von 7
Eine Crate publizieren
Um deine Library anderen zugänglich zu machen, veröffentlichst du sie auf
crates.io. Dafür braucht deine Cargo.toml Metadaten:
[package]
name = "meine_crate"
version = "0.1.0"
edition = "2021"
description = "Eine kurze Beschreibung"
license = "MIT OR Apache-2.0"
Wichtige Felder:
description— Pflicht für crates.iolicense— die Lizenz deines Codesversion— folgt SemVer (Major.Minor.Patch)
Dann cargo publish (nach cargo login mit deinem crates.io-Token).
SemVer in Kurzform
- Patch (0.1.x): Bugfixes, rückwärtskompatibel
- Minor (0.x.0): neue Features, rückwärtskompatibel
- Major (x.0.0): breaking changes
publish ist unwiderruflich
Einmal publiziert, bleibt eine Version für immer auf crates.io (du kannst
nur neue Versionen veröffentlichen, keine entfernen). Deshalb: Metadaten und
API vor dem ersten cargo publish sorgfältig prüfen.
✅ Wichtige Erkenntnisse
Haken setzen, um deinen Lernfortschritt zu markieren:
cargo install & der komplette Befehlssatz
Lektion 72 von 7
Binaries global installieren
Mit cargo install installierst du Binary-Crates global (z. B. ripgrep,
bat):
cargo install ripgrep
Das lädt die Crate von crates.io, baut sie und legt die Binary in
~/.cargo/bin/ ab.
Die wichtigsten cargo-Befehle
| Befehl | Zweck |
|---|---|
cargo build | Projekt kompilieren (dev) |
cargo build --release | optimiert kompilieren |
cargo run | bauen + ausführen |
cargo test | Tests ausführen |
cargo check | schnell auf Fehler prüfen |
cargo doc | Dokumentation bauen |
cargo fmt | Code formatieren |
cargo clippy | Lint-Warnungen (fängt Fallstricke) |
cargo publish | auf crates.io veröffentlichen |
cargo check & clippy sind deine Freunde
cargo check prüft nur auf Fehler, ohne voll zu bauen — viel schneller im
Editor-Loop. cargo clippy fängt idiomatische Fehler und Fallstricke, die der
Compiler nicht meldet. Beide sollte man regelmäßig laufen lassen.
✅ Wichtige Erkenntnisse
Haken setzen, um deinen Lernfortschritt zu markieren:
Übung: Ein Workspace mit Library & Binary
Lektion 73 von 7
Projekt: Ein kleines Workspace
Du baust ein Workspace, das Library und Binary trennt:
- Erstelle ein Workspace-Root mit
members = ["lib", "bin"]. - Lege eine Library-Crate
libmit einer Funktionverdopple(n: i32) -> i32an und dokumentiere sie mit///-Kommentar + Doc-Test-Beispiel. - Lege eine Binary-Crate
binan, dielibals Pfad-Abhängigkeit nutzt undverdoppleinmainaufruft. - Führe
cargo testim Root aus — bestätige, dass der Doc-Test mitläuft. - Baue mit
cargo build --releaseund prüfe, dass beide Crates kompiliert werden.
Das verbindet Workspaces, Pfad-Abhängigkeiten, Doc-Tests und Release-Profile.
Rezepte aus diesem Modul
- Profil anpassen:
[profile.release] opt-level = 3 - Workspace:
[workspace] members = [...] - Doc-Kommentar:
///(Item) und//!(Crate) - Pfad-Abhängigkeit:
crate = { path = "../crate" } - Publizieren: Metadaten +
cargo publish
Übung: Workspace mit Library & Binary
🧩 Übung m16-l7-e1
🔮 Vorhersage: Was passiert beim Ausführen?
✅ Wichtige Erkenntnisse
Haken setzen, um deinen Lernfortschritt zu markieren: