Haskell

Haskell は汎用の純関数型プログラミング言語です。

インストール

Haskell は Linux でネイティブに実行することができるマシンコードを生成します。(コンパイル済みの) バイナリのソフトウェアを実行するのに特別なものは必要ありません。公式リポジトリや ArchHaskell で提供されているソフトウェアと同じです。一方、AUR のパッケージやソースコードは、ソフトウェアをビルドするのにコンパイラを必要とします。

コンパイラをインストールするだけで Haskell のソースコードがビルドできるようになります。Haskell での開発を始めるためのツールのコンプリートセットである Haskell-Platform もあります。

コンパイラ

Haskell のソースコードをネイティブコードにビルドするには、コンパイラをインストールする必要があります。複数の 実装 が存在しますが、一番よく使われている (事実上のリファレンス実装となっている) のは GHC (Glasgow Haskell Compiler) です。公式リポジトリの ghc でインストールができます。

次のファイルを用意して:

Main.hs

main = putStrLn "Hello, World"

以下を実行して試すことができます:

$ ghc -dynamic Main.hs
$ ./Main 

Hello, World

設定

バージョン 8.0.2-1 以降、extra に含まれる Arch ghc パッケージと全ての haskell-* パッケージは動的にリンクされるライブラリのみを提供します。そのため、リンクに成功するためには GHC, Cabal, Stack を動的リンクに設定する必要があります。

動的リンクを使用すると、通常、(実行中の複数の Haskell プログラム間でページを共有することにより) ビルドが高速化され、ディスクと RAM の使用量が削減され、GHC 間の混合エラーのトラブルシューティングから解放されます。しかし、これには独自の欠点もあります。それは、ghc、ghc-libs、または org/packages/?q=haskell haskell-* パッケージは、GHC でコンパイルされたライブラリが安定した ABI を提供しないためです。このような壊れたバイナリを実行すると、通常のメッセージ error whileloadingsharedlibraries:libHS...so:cannotopensharedobjectfile:No such file or directory が表示されます。これを修正するには、壊れたツールを再構築して再インストールし、新しいライブラリに再リンクします。

一方、静的リンクは一般に保守が容易で、依存関係を更新するたびにすべてのツールをソースから再構築する必要がありません。これらの理由から、静的リンクは、パッケージシステム外のローカル開発では多くの場合推奨されるオプションです。 静的リンクを希望する場合、詳細については 静的リンク または 代替インストール を参照してください。

ノート: Arch が Haskell パッケージの動的リンクに移行した理由の詳細な説明については、この メンテナーの返答 を参照してください。

GHC を直接呼び出す

正常にリンクするには、-dynamic フラグを GHC に渡す必要があります。次のファイルで試すことができます。

Main.hs

main = putStrLn "Hello, World"

次のようにコンパイルして実行します。

$ ghc -dynamic Main.hs
$ ./Main

Hello, World

Cabal を動的リンク用に構成する

まず、次のコマンドを実行して、Hackage からパッケージの最新リストをダウンロードし、グローバル設定ファイル ~/.cabal/config (または、$CABAL_CONFIG が指すファイル) を作成します。

$ cabal update

ヒント: 定期的に cabal update を実行して、ローカルのパッケージと依存関係のリストを Hackage の最新バージョンと同期することをお勧めします。

Cabal を動的リンク用に設定するには、~/.cabal/config 内の次のオプションのコメントを解除して編集します。

~/.cabal/config

library-vanilla: False
shared: True
executable-dynamic: True
program-default-options
  ghc-options: -dynamic

• library-vanilla: False は静的ライブラリの作成を抑制します (プロジェクトにライブラリが含まれている場合)
• shared: True は共有ライブラリの作成を有効にします(プロジェクトにライブラリが含まれている場合)
• executable-dynamic: True は実行ファイルにダイナミックリンクを使用します (プロジェクトに実行ファイルが含まれている場合)
• ghc-options: -dynamic は GHC の全ての呼び出しに -dynamic フラグを追加します (例えば、パッケージが自明でないSetup.hs を持っている場合)

動的リンク用のスタックの設定

stack setup コマンドを使用してスタックを初期化し、グローバル設定ファイル ~/.stack/config.yaml を作成できます。デフォルトでは、スタックは最初の呼び出し時に独自のバージョンの GHC を隔離された場所に自動的にダウンロードします。代わりにスタックにシステム GHC インストールを使用させるには、--system-ghc フラグと --resolver フラグを指定して stack setup を実行します。

$ stack setup --system-ghc --resolver resolver

システムの GHC と互換性のあるリゾルバーを指定する必要があることに注意してください。それ以外の場合、スタックは --system-ghc フラグを喜んで無視し、GHC の独自のコピーをダウンロードします。システム GHC のバージョンは、ghc --version コマンドを使用して確認できます。

$ ghc --version

The Glorious Glasgow Haskell Compilation System, version 8.10.2

次に、Stackage Web サイトにアクセスし、システムの GHC バージョンに一致する適切な長期サポート (LTS) または夜間スナップショットを選択します。コマンドラインの --resolver フラグに対して選択したスナップショットを使用します。例:--resolver lts-16.15 または --resolver nightly-2020-09-01

Stackage は通常、新しい GHC リリースより遅れます。システム GHC のスタックスナップショットがまだリリースされていない場合があります。この場合、GHC の以前のマイナーバージョンのスナップショットを選択するか、Haskell インストールを一時的にダウングレードして、新しい GHC リリースのサポートが最終的に Stackage に提供されるまで待つことをお勧めします。

動的リンク用にスタックを構成するには、次のスニペットを ~/.stack/config.yaml に追加します。

~/.stack/config.yaml

# Stop downloading GHCs into isolated locations under ~/.stack.
install-ghc: false

# Allow Stack to pick the system GHC (false by default).
system-ghc: true

# Allow to use, say, Stackage snapshot for GHC 8.8.2 with system GHC 8.8.3.
compiler-check: newer-minor

# Add the -dynamic flag to every invocation of GHC.
ghc-options:
  "$everything": -dynamic

Haskell パッケージの管理

Haskell のライブラリと実行可能ファイルのほとんどは、Hackage および Stackage から入手できるソースパッケージの単位で配布されます。

他のコンパイル言語では一般的なことですが、多くの人気のある Haskell パッケージは、事前構築された形式で公式 Arch リポジトリから入手できます。いくつかの追加パッケージは AUR からインストールできます。

GHC、ライブラリ、およびツールをインストールするには pacman を使用することが推奨されますが、ある時点で、Hackage/Stackage から直接 Haskell パッケージをインストールしたり、ソースから独自の (または他の人の) パッケージをコンパイルしたくなるかもしれません。これを行うには、Cabal または Stack が必要になります。

次の表は、さまざまなパッケージ管理スタイルの長所と短所をまとめたものです。

方法	良い点	悪い点
公式リポジトリ	ArchLinux 開発者が運営、パッケージのバージョンの整合性に問題なし、コンパイル済み	利用できるパッケージの数が限られる、動的ライブラリのみ
cabal-install	全てのパッケージが利用可能、root 権限が不要	インストール先がホームフォルダ、cabal-install はパッケージマネージャではない、パッケージのバージョンの整合性に問題がある可能性 (別名 cabal hell)
stack	(Stackage にある) 全てのパッケージが利用可能、root 権限が不要	インストール先がホームフォルダで、バージョンがスナップショットに固定、特定のパッケージを削除するのは難しい
Arch User Repository	始めるのが簡単	パッケージのメンテナンスがなくなる可能性、パッケージのバージョンの整合性に問題がある可能性

cabal

ノート: Haskell では、cabal という用語は次のいずれかを指します。:

• Haskell パッケージとその依存関係を記述する Cabal ファイルフォーマット;
• Cabal ファイルフォーマットで動作する Cabal ライブラリ;
• Haskell パッケージをビルドするために Cabal ライブラリを使用する cabal コマンドラインツール (cabal-install パッケージで提供されます)

この記事の文脈では、Cabal は通常、特に指定がない限り cabal コマンドラインツールを意味します。

Cabal は Haskell の "オリジナル" のビルドシステムです。Hackage で見つかるライブラリやツールのほとんどは、Cabal 経由でインストールできます。

パッケージのインストール

Cabal によってインストールされたユーザー全体の実行可能ファイルを実行するには、~/.cabal/bin を $PATH 環境変数 に追加する必要があります。

PATH="$HOME/.cabal/bin:$PATH"

次のコマンドを実行して、Hackage パッケージとそのすべての依存関係を 1 つのステップでインストールします。

$ cabal install --ghc-options=-dynamic package

ノート: 2020年10月現在、Cabal は ~/.cabal/config の ghc-options を無視し、build-type: Custom を使ってパッケージをビルドしている間、~/.cabal/config の ghc-options を無視します。そのため、コマンドラインで --ghc-options=-dynamic フラグを指定する必要があります。そうしないと setup.hs で Could not find module 'Prelude' There are files missing in the 'base-...' package のようなビルドエラーが発生するかもしれません。

Haskell パッケージをソースからビルドしてインストールすることもできます。これを行うには、パッケージディレクトリから次のコマンドを実行します。

$ cabal install --ghc-options=-dynamic

各 Cabal パッケージは、パッケージ バージョン管理ポリシー (PVP) に従って、依存関係のリストとそのバージョン制約を .cabal ファイルに指定する必要があります。パッケージのインストール中に、Cabal はすべての制約を満たす一連の依存関係を見つけようとします。このプロセスは 依存関係の解決 と呼ばれます。

スタックが存在するのには理由があります。cabal は初心者との間に多くの軋轢を生むことで知られています。ほとんどの場合、依存関係の解決はうまく機能しますが、失敗する場合もあります。この場合、問題の原因を突き止め、問題のある依存関係を解決する方法について Cabal にヒントを与える必要があります。たとえば、場合によっては、Cabal がパッケージの PVP によって規定された依存関係の上限を無視できるようにするために、cabal install --allow-newer --ghc-options=-dynamic package と言う必要があります。バージョンを変更し、パッケージ作成者が許可したものよりも新しい依存関係を持つパッケージを効果的にインストールします。 あまり適切に管理されていないパッケージの場合は、さらに面倒になります。別の例については、Idris (Haskell で書かれた別のプログラミング言語) のインストールに関する このスレッド を参照してください。--allow-newer および --constraint='haskeline < 0.8.0.0' コマンドラインフラグを使用してコンパイルを成功させます。

パッケージの削除

簡単な方法はありません。 Cabal はこの機能をサポートしていませんが、cabal-store-gc のような外部ツールがあります。

ユーザー全体の Haskell パッケージ システム全体を再インストールするには、~/.cabal と ~/.ghc を削除して、最初から始めます。これは、GHC をアップグレードするときに必要になることがよくあります。

より正確に行うには、ghc-pkg unregister package または ghc-pkg hide package/ghc-pkg expose package を user package database 上で直接使うことができます。しかし、どちらもファイルを削除しません。

Stack

Stack は、Haskell パッケージを管理するためのもう 1 つのツールです。それは cabal とは少し異なる目標を持ち、少し異なる哲学を持っています。これは内部で Cabal ライブラリを使用し、Hackage と統合します。ただし、スナップショットが厳選され、連携して適切に動作するパッケージが含まれることを約束して、独自のパッケージ (スナップショット) リポジトリを Stackage 上に維持します。

パッケージのインストール

デフォルトの設定では、Stack はコンパイル済みの実行ファイルを ~/.local/bin にインストールします。このディレクトリをシェル設定ファイルの $PATH 環境変数に追加してください。例えば bash なら ~/.bashrc、zsh なら ~/.zshrc です:

export PATH="$HOME/.local/bin:$PATH"

次のコマンドを実行して、Stackage パッケージをダウンロード、ビルド、インストールします。

stack install package

ノート: 2020 年 10 月現在 Stackは、ignores ~/.stack/config.yaml から ghc-options を Setup.hs ビルド時に無視します。もし Setup.hs で Could not find module 'Prelude' There are files missing in the 'base-...' package のようなビルドエラーが発生したら、ghc-static パッケージをインストールしてみてください。

パッケージディレクトリから次のコマンドを実行して、ソースから Haskell パッケージをビルドしてインストールすることもできます。

stack install --resolver resolver

stack setup コマンドで使用したものと同じリゾルバーを指定する必要があることに注意してください。

パッケージの削除

スタックは "アンインストール" 操作をサポートしていません。

ユーザー全体の Haskell パッケージシステム全体を再インストールする場合は、~/.stack ディレクトリを削除して、最初から始めてください。これは、GHC をアップグレードするときに必要になることがよくあります。

開発ツール

ツール

haskell-language-server

haskell-language-server は、Haskell の 言語サーバープロトコル (LSP) 実装です。これは、コード補完、"定義に移動"、ホバーに関するドキュメント、リンティング、書式設定、または LSP と統合されたエディターのリファクタリングなどの IDE のような機能を提供します。

pacman から動的にリンクされた Haskell パッケージを使用している場合は、haskell- language-server をインストールします。それ以外の場合、静的リンクを希望する場合は、haskell-langage-server-static^AUR をインストールしてください。このパッケージには、サポートされている GHC バージョンごとに静的にリンクされたバイナリが含まれています。あるいは、haskell-language-server は ghcup 経由、または Visual Studio Code の Haskell 拡張機能 によってインストールできます。

haskell-language-serverは、プロジェクトを開いたときに自動的にビルド構成を決定しようとします。自動判別に失敗した場合は、プロジェクトのルートディレクトリにある hie.yaml ファイルを使って 手動で設定する とよいでしょう。

ghcid

ghcid は、Haskell 開発用の GHCi ベースのツールです。は、ソースコードの変更ごとにコンパイラエラーと警告を表示するシンプルかつ堅牢な方法を提供します。ghcid^AUR パッケージ経由でインストールできます。

hoogle

hoogle を使用すると、関数名またはおおよその型シグネチャによって Haskell ライブラリを検索できます。hoogle パッケージ経由でインストールできます。

hoogle のオンライン版は https://hoogle.haskell.org で入手できます。

リンター

hlint

hlint は、代替関数の使用、コードの簡素化、冗長性の特定など、Haskell コードの改善の可能性を示唆しています。これは、hlint パッケージを通じて入手できます。

stan

stan は、hlint を補完する Haskell 静的アナライザーです。2021 年 6 月現在はベータ段階です。

weeder

weeder はプログラム全体のデッドコード解析を行うアプリケーションです。

フォーマッタ

• brittany — Haskell ソースコードフォーマッタ

https://github.com/lspitzner/brittany || haskell-brittany

• {App|Floskell|柔軟性と設定可能性に焦点を当てた hindent のフォーク|https://github.com/ennocramer/floskell%7Chaskell-floskell}}
• {App|fourmolu|様々な書式パラメータを設定する機能を追加した Ormolu のフォーク|https://github.com/parsonsmatt/fourmolu%7Chaskell-fourmolu}
• {{App|hindent|拡張可能な Haskell プリンター|https://github.com/mihaimaruseac/hindent%7Chindent}
• {{App|Ormolu|Haskell ソースコード用のフォーマッタで、設定を必要としない "真の" 書式スタイルを実装しています。|https://github.com/tweag/ormolu%7Chaskell-ormolu}
• stylish-haskell — シンプルな Haskell コードの整形ツール。

https://github.com/jaspervdj/stylish-haskell || {Pkg}

エディタ

Visual Studio Code

Visual Studio Code には、haskell-language-server を利用した Haskell 拡張機能 があります。haskell-language-server がインストールされていない場合は、Haskell 拡張機能が静的にリンクされた Linux バイナリを自動的にダウンロードしてインストールします。

IntelliJ IDEA

IntelliJ IDEA Haskell のサポートは、Haskell プラグイン によって提供されます。 intellij-idea-community-edition を含む IntelliJ IDEA のどのエディションでも動作します。

新しいプロジェクトを作成するか、既存のプロジェクトを IntelliJ IDEA にインポートするには、Stack をインストールする必要があります。2021 年 6 月現在、Cabal のみのプロジェクト はサポートされていません

Vim

Vim の基本的な設定のハイライトとインデントは、haskell-vim プラグインを介して取得できます。IDE のようなエクスペリエンスを向上させるには、LSP client プラグイン (例:coc.nvim、[https: //github.com/dense-analysis/ale ALE]、LanguageClient-neovim) と haskell- language-server

Emacs

Haskell の基本的な Emacs サポートは、公式 haskell-mode によって提供されます。より高度な機能については、lsp-haskell を haskell-language-server とともに使用してください。

代替インストール

ノート: このセクションでは、公式リポジトリのパッケージを使用せずに、Haskell を Arch にインストールする別の方法について説明します。以前に GHC、Cabal、Stack、またはその他の Haskell パッケージをインストールした場合は、必ず最初にそれらをアンインストールしてください。~/.cabal ディレクトリと ~/.stack ディレクトリが存在する場合は削除します。

汎用 Linux ディストリビューションに Haskell をインストールするには、ghcup と Stack という 2 つの公式に推奨される方法があります。どちらの方法でも、静的にリンクされた GHC、ツール、ライブラリがホーム ディレクトリにインストールされます。

公式リポジトリの Haskell パッケージの代わりに ghcup または Stack を使用する利点は、複数のバージョンの GHC を並べてインストールして管理できることです。この方法でインストールされた Cabal と Stack は通常、追加の設定を行わずにすぐに動作するため、初心者にとっては簡単かもしれません。

Haskell をインストールするまったく異なる方法は、Nix パッケージ マネージャーです。Nix は学習曲線がより急峻ですが、Haskell パッケージと非 Haskell パッケージの両方を信頼性が高く再現可能な方法で管理する上でより高い柔軟性を提供します。

ghcup

ghcup は、GHC の複数のバージョンを簡単にインストールし、それらを切り替えることができるコマンドラインツールです。これは、[1]、pyenv、および jenv とスコープが似ています。

ghcup-hs-bin^AUR パッケージをインストールしてください。あるいは、公式の インストール手順 に従うか、手動で ghcup バイナリ をダウンロードして $PATH のどこかに置いてください。

デフォルトでは、ghcup は GHC 実行ファイルを ~/.ghcup/bin にインストールします。このディレクトリをシェル設定ファイルの $PATH 環境変数に追加する必要があります。例えば bash なら ~/.bashrc、zsh なら ~/.zshrc です。Cabal によってインストールされた実行可能ファイルを実行したい場合は、~/.cabal/bin も $PATH に追加してください:

export PATH="$HOME/.cabal/bin:$HOME/.ghcup/bin:$PATH"

ヒント: XDG スタイルのディレクトリを使用する場合は、GHCUP_USE_XDG_DIRS 環境変数 (https://ghcup.readthedocs.io/en/latest/guide/#xdg-support) を定義します。

ghcup は、その機能のほとんどをサポートする便利な TUI を提供します。

$ ghcup tui

あるいは、次の CLI コマンドを使用することもできます。

GHC と Cabal の利用可能なバージョンをリストします。

$ ghcup list

推奨バージョンの GHC をインストールします。

$ ghcup install ghc

たとえば、GHC の特定のバージョンをインストールすることもできます。

$ ghcup install ghc 8.10.2

上記のコマンドでは、GHC が $PATH で自動的に利用可能になるわけではありません。デフォルトで使用する GHC バージョンを選択する必要があります。

$ ghcup set ghc 8.10.2

Cabal の推奨バージョンをインストールします。

$ ghcup install cabal

Cabal を使用して、特別な設定やコマンドラインフラグを必要とせずに、静的にリンクされた Haskell 実行可能ファイルをビルドおよびインストールできるようになりました。

$ cabal update
$ cabal install executable

新しい Cabal プロジェクトを開始するには:

$ cd /path/to/my-project
$ cabal init
$ cabal build
$ cabal run

Up to date
Hello, Haskell!

haskell-language-server をインストールするには、次のコマンドを使用します。

$ ghcup install hls

詳細については、公式 ghcup および Cabal ドキュメントを参照してください。

Stack

stack-static^AUR パッケージをインストールします。あるいは、公式の インストール手順 に従うか、スタックバイナリ を手動でダウンロードして、それをあなたの $PATH に配置することもできます。

スタックによってインストールされた実行可能ファイルを実行したい場合は、シェル設定ファイルの $PATH 環境変数に ~/.local/bin ディレクトリを追加します (例:<code~/.bashrc>~/) bash の場合は、{ic zsh の場合は ~/.zshrc:

export PATH="$HOME/.local/bin:$PATH"

stack setup を実行して、最新のスタック LTS スナップショットから GHC を自動的にインストールします。

$ stack setup

特別な設定やコマンドラインフラグを必要とせずに、Stack を使用して静的にリンクされた Haskell パッケージを構築およびインストールできるようになりました。

$ stack install package

詳細については、公式 Stack ドキュメント を参照してください。

ヒントとテクニック

静的リンク

ノート:

• このセクションでは、静的にリンクされた Haskell パッケージを Arch 上でビルドしながら、公式リポジトリからインストールされた GHC を使用する方法について説明します。続行する前に、~/.cabal ディレクトリと ~/.stack ディレクトリが存在する場合は必ず削除してください。
• この記事の文脈において、静的リンクは完全に静的な ELF バイナリを生成することを意味するものではありません。Haskell コードのみが単一の ELF バイナリに静的にリンクされ、それは glibc などの他のシステムライブラリに動的にリンクされる場合があります。

静的リンクを使用するには、少なくとも、ghc-static パッケージを通じて静的ブートライブラリをインストールする必要があります。これにより、ブートライブラリだけでなく、公式リポジトリから haskell-* パッケージを通じてインストールされない他のライブラリにもっぱら依存するプロジェクトをビルドできるようになります。

残念ながら、プロジェクトがインストールした動的にリンクされた haskell-* パッケージのいずれかに依存している場合、Cabal は依存関係の解決時に静的ライブラリの不在を考慮しません。その結果、既存の haskell-* パッケージを使用しようとし、静的ライブラリを検出すると linker errors で失敗します。:

Could not find module ‘SomePackage.SomeModule’
There are files missing in the ‘somepackage-0.1.0.0’ package,
try running 'ghc-pkg check'.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.

ghc-staticとは異なり、連携可能な "haskell-*-static" パッケージはありません。ただし、以下の各セクションで説明するように、この問題を回避する他の方法もあります。

静的グローバルパッケージデータベース

直接的な アプローチ は、公式の ghc-static パッケージによって提供されており、代替の "静的" パッケージが公開されています。グローバルパッケージデータベース(/usr/lib/ghc-version/static-package.conf.d)静的データベースは、静的にリンク可能なブートパッケージのみに制限されているため、デフォルトデータベースの代わりに静的データベースを使用するように Cabal が再構成されている場合、動的専用の haskell-* パッケージがリンクされていないかのように動作します。

静的データベースの正確なパスは、次のようなコマンドを使用して構築時に決定できます。

$ ghc --print-global-package-db | sed 's/\(package\.conf\.d\)$/static-\1/'

/usr/lib/ghc-version/static-package.conf.d

静的データベースを使用できるようにする方法は次のとおりです。

• Cabal でパッケージを構築する場合、次のフラグを渡すと、グローバルパッケージの選択をブートパッケージのみに制限できます。

$ cabal configure --ghc-pkg-option="--global-package-db=$(ghc --print-global-package-db | sed 's/\(package\.conf\.d\)$/static-\1/')"

• Cabal ではなく GHC を使用して直接ビルドする場合、次のフラグを渡してグローバルパッケージデータベースをオーバーライドできます。

$ ghc -clear-package-db -package-db "$(ghc --print-global-package-db | sed 's/\(package\.conf\.d\)$/static-\1/')" -user-package-db ...

ghc-pristine

ghc-pristine^AUR パッケージをインストールします。このパッケージは既存の GHC インストールをラップして、ブートライブラリのみを含むパッケージデータベースを備えた別の GHC ディストリビューションを /usr/share/ghc-pristine に作成します。これにより、動的にリンクされた haskell-* パッケージを使用せずに半分離環境が効果的に作成されますが、それでも公式リポジトリの GHC コンパイラーが利用されます。次に、静的リンクを使用してソフトウェアを構築するには、ラップされたコンパイラー /usr/share/ghc-pristine/bin/ghc を呼び出すだけです。Cabal の場合、これは ~/.cabal/config の次の構成に相当します。

~/.cabal/config

with-compiler: /usr/share/ghc-pristine/bin/ghc

プロジェクトディレクトリから次のコマンドを実行して、プロジェクトごとにコンパイラへのパスを指定することもできます。

$ cabal configure --with-compiler=/usr/share/ghc-pristine/bin/ghc

cabal-static

Arch で静的リンクを取り戻すもう 1 つの方法は、cabal-static^AUR パッケージをインストールすることです。公式の cabal-install とは異なり、これは動的にリンクされた haskell-* の依存関係を公式リポジトリから取得せず、同じシステムにインストールされた静的 Haskell ライブラリと共有 Haskell ライブラリの混合を回避します。その後、次の制限付きで通常どおり Cabal を使用できます: インストールした他の Haskell パッケージが ghc、ghc-libs のみであることを確認する必要があります。および ghc-static (cabal-install、stack、および公式リポジトリで入手可能な haskell-* パッケージではありません。)

stack-static

stack-static^AUR パッケージをインストールします。cabal-static メソッドと同様に、公式リポジトリからインストールした他の Haskell パッケージが ghc、ghc-libs、および ghc-static のみであることを確認してください。次に、Haskell#動的リンク用のスタックの設定 で説明されているように、システム GHC を使用するようにスタックをセットアップします。

$ stack setup --system-ghc --resolver resolver

これらのオプションを永続的にするには、次のスニペットを ~/.stack/config.yaml に貼り付けます。

~/.stack/config.yaml

# Stop downloading GHCs into isolated locations under ~/.stack.
install-ghc: false

# Allow Stack to pick the system GHC (false by default).
system-ghc: true

# Allow to use, say, Stackage snapshot for GHC 8.8.2 with system GHC 8.8.3.
compiler-check: newer-minor

この設定では、通常と同じように静的にリンクされたパッケージをビルドできますが、Stack によって提供される GHC の代わりにシステム GHC インストールを使用します。

hpack-static-bin

hpack-static-bin^AUR は、haskell-hpack の代わりに静的にリンクされた (haskell-* 依存関係がないことを意味します) を提供します。プリコンパイルされているため、make 依存関係は必要ありません。

ghcup

ghcup は、GHC をシステムパッケージマネージャーの外部でローカルにインストールできるツールです。さらに、複数のバージョンの GHC を並行してサポートします。このツールが提供する GHC を使用すると、システム GHC がまったく使用されないため、静的リンクに関連する問題が完全に回避されます。また、システム GHC とそのブートライブラリのアップグレードによって引き起こされる、ローカルに構築されたライブラリの破損も自然に回避されます。

参照

• すごいHaskellたのしく学ぼう! (英語版)
• Real World Haskell