Haskell · Build · Tooling

Stack vs. Cabal: ein Haskell-Build-Tool wählen

Sobald ein Haskell-Compiler installiert ist, brauchen Sie einen Weg, Abhängigkeiten zu verwalten und Ihr Projekt zu bauen. 2026 gibt es zwei Mainstream-Optionen: Cabal und Stack. Sie erledigen dieselbe Grundarbeit — Bibliotheken holen, Ihren Code bauen, Tests ausführen — treffen aber unterschiedliche Abwägungen, woher die Pakete kommen und wie reproduzierbar die Builds sind. Dieser Leitfaden erklärt, was jedes ist, worin sie sich unterscheiden, die äquivalenten Befehle und wie man wählt.

Was Cabal ist

Cabal ist das ursprüngliche Build-System von Haskell. Der Begriff umfasst zwei Dinge: die Cabal-Bibliothek/-Spezifikation (das .cabal-Dateiformat, das ein Paket beschreibt) und cabal-install, das Kommandozeilen-Tool cabal, das Pakete baut und Abhängigkeiten auflöst. Standardmäßig holt es Bibliotheken von Hackage, dem zentralen Archiv der Haskell-Pakete.

Das moderne Cabal nutzt nix-artige lokale Builds (die früheren v2--Befehle, inzwischen Standard), die jedem Projekt einen isolierten Build und einen gemeinsamen globalen Store gebauter Pakete geben. Ein Abhängigkeits-Solver wählt die Versionen, die die von Ihnen deklarierten Schranken erfüllen:

-- in your .cabal file
build-depends: base >=4.14 && <5, text, aeson ^>=2.1

Der Caret-Operator ^>= bedeutet „mindestens diese Version, erlaube aber nur spätere kompatible Versionen“. Projektweite Einstellungen leben in einer cabal.project-Datei. Es ist die Toolchain, die am engsten an den Releases von GHC und Hackage ausgerichtet ist.

Was Stack ist

Stack ist ein Build-Tool, das rund um die Reproduzierbarkeit entworfen wurde. Statt Versionen gegen ganz Hackage aufzulösen, baut es gegen einen Stackage-Snapshot: eine kuratierte Menge von Paketversionen, von denen bekannt ist, dass sie zusammen kompilieren. Sie pinnen einen Snapshot in stack.yaml:

resolver: lts-22.14
packages:
  - .

Da der Snapshot jede Version festlegt, erhält jeder, der Ihr Projekt holt und stack build ausführt, dieselben Abhängigkeitsversionen — und Stack installiert automatisch das zum Snapshot passende GHC. Diese „läuft überall gleich“-Garantie ist der Hauptreiz von Stack, besonders für Teams und CI.

Die zentralen Unterschiede

• Paketquelle — Cabal löst gegen ganz Hackage auf; Stack baut gegen einen kuratierten Stackage-Snapshot. Stackage tauscht etwas Aktualität gegen garantiert kompatible Mengen.
• Reproduzierbarkeit — Stack pinnt standardmäßig alles über den Snapshot. Cabal kann mit einer cabal.project.freeze-Datei genauso reproduzierbar sein, aber Sie aktivieren es explizit.
• GHC-Verwaltung — Stack lädt herunter und verwaltet die GHC-Version, die ein Snapshot braucht. Mit Cabal bringen Sie Ihr eigenes GHC mit (üblicherweise installiert über GHCup).
• Konfigurationsdateien — beide lesen die .cabal-Datei des Pakets. Stack ergänzt stack.yaml; Cabal ergänzt cabal.project.
• Ökosystem-Ausrichtung — Cabal folgt eng den Releases von GHC und Hackage; Stack rückt im Takt der Snapshot-Kuration vor.

Die äquivalenten Befehle

Im Alltag ähneln sich beide:

-- Cabal                  -- Stack
cabal build               stack build
cabal run myapp           stack run
cabal test                stack test
cabal repl                stack ghci
cabal haddock             stack haddock

Beide steuern denselben Compiler im Unterbau — siehe den GHC-Leitfaden für die Optionen, die zählen. Beachten Sie, dass das heutige Cabal vom Workflow abstammt, der in Cabal 2.0 eingeführt wurde, das den älteren Ansatz der Sandboxes ablöste.

Welches sollte man wählen?

2026 sind beide gut und werden aktiv gepflegt — es ist kein Fall, in dem eines veraltet wäre. Eine vernünftige Faustregel:

• Wählen Sie Cabal, wenn Sie die GHC-ausgerichtete Standard-Toolchain, die neuesten Paketversionen von Hackage und feine Kontrolle über Versionsschranken möchten. Das ist der Weg, den die meisten neuen Tutorials voraussetzen.
• Wählen Sie Stack, wenn Sie schlüsselfertige Reproduzierbarkeit und automatische GHC-Verwaltung schätzen, oder wenn Sie in einem Team sind, in dem „alle bekommen denselben Build“ mehr zählt als die neuesten Bibliotheksversionen.

Sie müssen sich nicht für immer entscheiden: GHCup installiert beide, und viele Projekte liefern eine stack.yaml und eine cabal.project, damit Mitwirkende das eine oder das andere nutzen können. Probieren Sie eines aus und wechseln Sie, wenn seine Abwägungen nicht passen.

FAQ

Cabal oder Stack, was ist besser? Keines ist strikt besser; sie optimieren für unterschiedliche Dinge. Cabal bevorzugt aktuelle Hackage-Versionen und die enge Ausrichtung auf GHC; Stack bevorzugt kuratierte, reproduzierbare Snapshots und die automatische GHC-Installation.

Nutzen Stack und Cabal dasselbe Paketformat? Ja. Beide lesen die .cabal-Datei des Pakets. Stack ergänzt darüber stack.yaml; Cabal ergänzt cabal.project.

Was ist ein Stackage-Snapshot? Eine kuratierte Menge von Hackage-Paketversionen, die geprüft sind, zusammen zu kompilieren, identifiziert durch einen Resolver wie lts-22.14. Einen zu pinnen macht Builds reproduzierbar.

Kann ich später von Stack zu Cabal wechseln? Meist ja — die .cabal-Datei wird geteilt, also ergänzen Sie vor allem eine cabal.project und stellen ein GHC bereit (über GHCup). Versionsschranken können etwas Aufräumen erfordern.

Neu in der Toolchain? Beginnen Sie mit Haskell mit GHCup installieren, das GHC, Cabal und Stack zusammen einrichtet.