Release-Profile & Optimierung

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).

Eigene Profile & Optimierungs-Feinheiten

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 Optimierung
• panic = "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.

Workspaces: mehrere Crates verwalten

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 build baut alle Mitglieder
• Crates können sich gegenseitig mit Pfad-Abhängigkeiten nutzen

# adder/Cargo.toml
[dependencies]
add_one = { path = "../add_one" }

Dokumentation: doc-Kommentare

/// 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.

Veröffentlichen auf crates.io

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.io
• license — die Lizenz deines Codes
• version — 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

cargo install & der komplette Befehlssatz

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

Übung: Ein Workspace mit Library & Binary

Projekt: Ein kleines Workspace

Du baust ein Workspace, das Library und Binary trennt:

1. Erstelle ein Workspace-Root mit members = ["lib", "bin"].
2. Lege eine Library-Crate lib mit einer Funktion verdopple(n: i32) -> i32 an und dokumentiere sie mit ///-Kommentar + Doc-Test-Beispiel.
3. Lege eine Binary-Crate bin an, die lib als Pfad-Abhängigkeit nutzt und verdopple in main aufruft.
4. Führe cargo test im Root aus — bestätige, dass der Doc-Test mitläuft.
5. Baue mit cargo build --release und prüfe, dass beide Crates kompiliert werden.

Das verbindet Workspaces, Pfad-Abhängigkeiten, Doc-Tests und Release-Profile.

Übung: Workspace mit Library & Binary