Build

Praxis-Nachtrag: Nutze Build in einem Mini-Szenario. Eine kleine App soll einen Nutzer anmelden, eine Liste laden oder eine Bestellung speichern. Frage: An welcher Stelle taucht Build auf, was würde ohne diesen Baustein fehlen, und welchen Fehler würdest du als Anfänger wahrscheinlich sehen? Diese Denkweise macht den Begriff sofort greifbarer als eine reine Definition.

Je nach Sprache anders:

• Java: ./gradlew build -> Erzeugt eine .jar Datei.
• JavaScript/Node: npm run build -> Minifiziert JS, transpiliert TypeScript zu JS.
• Docker: docker build -t my-app . -> Erzeugt ein Image.

In einer CI-Pipeline (GitHub Actions): Der Build ist fast immer der erste Schritt. Wenn der Build fehlschlägt ("Compile Error"), stoppt alles. Das ist gut! Lieber bricht der Build ab, als dass kaputte Software auf den Server kommt.

1. Incremental Builds

Große Projekte (Google Chrome, Linux Kernel) brauchen Stunden zum Bauen. Niemand will 4 Stunden warten, nur weil er eine Zeile geändert hat. Inkrementelle Builds (Smart Rebuilds) prüfen: "Hat sich Datei A geändert?". Nein? -> Nutze das alte .o File (Object File) aus dem Cache. Ja? -> Kompiliere nur Datei A neu und linke es zusammen. Tools wie Bazel (Google) oder Gradle sind Meister darin. Sie nutzen Hash-Bäume (DAGs), um Abhängigkeiten zu tracken.

2. Multi-Stage Builds (Docker)

Um Docker Images klein zu halten, nutzt man Multi-Stage Builds. Stage 1 (Builder): Hat alle Tools (Compiler, Maven, Node.js). Baut das Artefakt. Image ist riesig (1 GB). Stage 2 (Runner): Hat nur das Betriebssystem und das Artefakt. Kopiert das Artefakt aus Stage 1. Ergebnis: Ein winziges Image (50 MB) ohne unnötigen Ballast (Compiler, Source Code). Das erhöht Sicherheit (Angriffsfläche minimiert) und Performance.

3. Deterministic Builds

Das Ziel: "Gleicher Input -> Exakt gleicher Output (Hash)". Probleme: Zeitstempel (build_time = now()), Pfade (/home/user/project), Zufallszahlen. Lösung:

• Setze Zeitstempel auf 0 (Epoch 1970) oder Git Commit Time (SOURCE_DATE_EPOCH).
• Nutze relative Pfade. Nur so kann man Binary Verification machen (Verhindern von "SolarWinds" Supply Chain Attacks).

1. Build Tools vs. Build Systems

Ein Build Tool (wie gcc oder tsc) nimmt eine Eingabedatei und kompiliert sie stur. Ein Build System (wie Make, Maven, Gradle) koordiniert hunderte dieser Operationen. Es löst Abhängigkeitsgraphen (Dependency DAG) auf. Wenn Modul B von Modul A abhängt, wartet das Build System, bis A fertig ist, bevor es B an den Compiler übergibt. Es managed Cache-Misses und Invalidation (z.B. Make checkt, ob die Ticks (Last Modified) der .c neuer sind als die der .o Dateien).

2. Static vs. Dynamic Linking

Nach dem Kompilieren muss gelinkt werden.

• Static Linking (.a / .lib): Der Linker kopiert alle benötigten Drittanbieter-Funktionen physisch direkt in dein riesiges .exe Binary. Vorteil: Zero Dependencies. Lauffähig auf jedem System.
• Dynamic Linking (.so / .dll): Dein Binary bleibt winzig. Es enthält nur einen Verweis: "Lade zur Laufzeit die libc.so". Vorteil: Das Betriebssystem lädt die DLL ins RAM und teilt sie mit 100 anderen Prozessen, das spart Speicherplatz. Nachteil: "DLL Hell" (es fehlt eine Datei oder liegt in der falschen Version vor).

3. Tree Shaking & Dead Code Elimination

Im modernen Frontend-Build (z.B. Webpack, Vite via esbuild) ist Tree Shaking essenziell. Wenn du eine gigantische Library importierst, aber nur eine kleine Funktion nutzt:

import { isArray } from 'lodash';

...analysiert der Bundler den Abstract Syntax Tree (AST). Er erkennt und entfernt alle restlichen hunderte Funktionen (den "toten Code"), die niemals aufgerufen werden, und schrumpft dein fertiges Bundle (Artefakt) effektiv von 500 KB auf 2 KB herunter. Das rettet die Ladezeit der Website für Kunden am Smartphone drastisch.