Haskell

提供: ArchWiki
2023年8月2日 (水) 17:53時点におけるKgx (トーク | 投稿記録)による版 (開発ツールを翻訳して追加)
ナビゲーションに移動 検索に移動

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 から、Arch の ghc パッケージには GHC プラットフォームライブラリの静的バージョンが含まれていません。community リポジトリの haskell-* パッケージも同じです。GHC はデフォルトで静的リンクを使用します、動的リンクを使うときには -dynamic フラグを使用します。Cabal の場合、以下のようになります: 

$ cabal configure --disable-library-vanilla --enable-shared --enable-executable-dynamic
  • --disable-library-vanilla は静的ライブラリの作成を止めます (プロジェクトにライブラリが含まれる場合)。
  • --enable-shared は共有ライブラリの作成を有効にします (プロジェクトにライブラリが含まれる場合)。
  • --enable-executable-dynamic は実行ファイルで動的リンクを使用します (プロジェクトに実行ファイルが含まれる場合)。

~/.cabal/config に上記のフラグを設定することで、デフォルトで全てのプロジェクトで動的リンクを使うことができます: 

~/.cabal/config
library-vanilla: False
shared: True
executable-dynamic: True

pacman でパッケージ化されている Haskell モジュールの多くは動的リンクを使っており、AUR のパッケージも同様です。GHC はコンパイラのバージョン間で ABI 互換性を維持していないため、パッケージシステムから外れたローカルの開発環境では静的リンクを使うことが推奨されます。

ノート: この記事では、静的リンクとは完全に静的な ELF バイナリの生成を意味しません。単体の ELF バイナリに静的リンクされるのは Haskell のコードだけで、glibc など他のシステムライブラリは動的リンクされる可能性があります。

静的リンク

静的リンクを使うには、最低でも ghc-static パッケージで静的ブートライブラリをインストールする必要があります。ブートライブラリや haskell-* パッケージでインストールされないライブラリに依存するプロジェクトをビルドできるようになります。

残念ながら、プロジェクトが haskell-* パッケージのどれかに依存する場合、Cabal は依存関係を解決するときに静的ライブラリが存在しないことを考慮しません。したがって、既存の haskell-* パッケージを使用しようとすると リンカのエラー によって静的ライブラリが存在しないことがわかります。ghc-static と違って、問題を解決するための haskell-*-static パッケージは存在しません。

問題を回避するために、ghc-pristineAUR をインストールして既存の GHC 環境をラッピングして /usr/share/ghc-pristine に別の GHC 環境を作成することができます。パッケージデータベースにはブートライブラリのみが含まれます。静的リンクでソフトウェアをビルドするときは、ラッピングされたコマンド /usr/share/ghc-pristine/bin/ghc を実行します。Cabal の場合、以下のようになります: 

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

(cabal user-config init で作成される) ~/.cabal/config を編集することで設定を永続化できます。ghc-static は依然として必要なので注意してください。

ghc-pristine の代わりに以下の方法もあります:

  • cabal install --force-reinstalls を手動で実行して対応する haskell-* パッケージを遮蔽する。既存の haskell-* パッケージと重なる依存パッケージを全て指定する必要があるため面倒です。
  • 完全に分離された GHC 環境を使用する: GHC と cabal-install の公式 Linux バイナリをダウンロードしてどこかに展開する。ghc-pristine と同じことになりますが、ghc-pristine の方が必要なディスク容量が小さくてすみます。

Cabal で静的にリンクしたパッケージをビルド (共有ライブラリを使用しない)

このセクションでは公式の cabal-install パッケージの代わりに Hackage から cabal-install をインストールする方法を説明します。動的リンクが必要な公式の cabal-install と異なり、Hackage の cabal-install は 共有ライブラリ を使用せずに Haskell パッケージをビルドします。

原則的に cabal-install では Haskell のコードをリンクする時に静的・動的どちらの方法も選択できます。Arch では基本的な Haskell ライブラリ (haskell-* パッケージ) が共有オブジェクト (.so ファイル) として用意されており Cabal でグローバルにライブラリが登録されるため、静的リンクで同じライブラリを使用すると問題が起こります。リンクの エラー を避けるために、同じ環境に静的・動的な Haskell パッケージを混在させてはいけません。どちらかのパッケージがグローバルに登録されている場合 (ghc-pkg list コマンドで確認できます)、Cabal は必要なパッケージを取得しません (必要なパッケージのリンクの種別は関係ありません)。

そのため、インストールする Haskell 関連のパッケージはコンパイルの ghc と静的ブートライブラリの ghc-static だけに限ります (stack, cabal-helper[リンク切れ: パッケージが存在しません], cabal-install, 公式リポジトリに存在する haskell-* 動的ライブラリ [1] はインストールしません)。

Haskell パッケージのビルドツールとして Stack を使うこともできます。Stack はデフォルトで静的リンクを使います。Cabal で静的リンクを使ってビルドしたい場合、以下の手順に従うことで Hackage から cabal-install をインストールできます。ここで Stack ツールは必要な依存パッケージを取得して cabal-install をビルドするのに使用します。

まず stack-binAUR[リンク切れ: パッケージが存在しません] をインストールしてください。Cabal のコンパイルをブートストラップするのに使用します。依存パッケージとして haskell-* 動的ライブラリを含む公式 Arch リポジトリのパッケージを使うことはしません。

それから Stack のパッケージインデックスをダウンロードします。Stack は cabal-install のコンパイルをブートストラップするためだけに使いますが、インストール済みの ghc コンパイルも使用します: 

$ stack setup --system-ghc

そして cabal-install をインストール: 

$ stack install --system-ghc cabal-install

新しくインストールされる cabal-install は共有ライブラリを使わずにコンパイルされ、パッケージをビルドするときにデフォルトで共有ライブラリを使用しません。また、cabal-install はインストールされた ghc コンパイラを使用します。

Haskell Platform

Haskell での開発を簡単に始められる、haskell-platform バンドルは次のように説明されます:

Haskell のプログラミングを始める一番簡単な方法です。立ち上げて動作させるのに必要な全てが入っています。次のように考えて下さい "Haskell: batteries included" (電池付属)。

公式リポジトリから以下のパッケージをインストールすることで Haskell Platform を置き換えられます:

  • ghc (ghc) — 動的 ブートライブラリ (ghc-libs) が付属するコンパイラ。静的ブートライブラリ (ghc-static) は別個にインストールが必要です。
  • cabal-install (cabal-install) — Hackage の依存解決とパッケージの取得に焦点が置かれたビルドツール。
  • stack (stack) — Stackage の厳選されたスナップショットとパッケージの取得に焦点が置かれたビルドツール。
  • haddock (haskell-haddock-api[リンク切れ: アーカイブ: aur-mirror] と haskell-haddock-library) — ドキュメントを生成するためのツール
  • alex (alex) — 字句解析器ジェネレータ
  • happy (happy) — パーサジェネレータ

また、[2] に従って stack を使って Haskell 環境を管理する方法もあります。

Haskell パッケージの管理

Haskell ライブラリや実行可能ファイルの多くはパッケージにまとめられています。どれも Hackage から利用することが可能です。また、厳選されたパッケージが Stackage に存在します。パッケージをインストール・管理する方法は複数存在します:

cblrepo は Linux ディストリビューションの Haskell パッケージを管理するために使用するツールです。これのラッパーである、cabal2pkgbuild-gitAUR[リンク切れ: アーカイブ: aur-mirror] は Hackage パッケージから PKGBUILD を作成することができます。新しい Haskell パッケージを作成することについては Haskell パッケージガイドラインに詳しく記載があります。

方法ごとのプラス面とマイナス面

以下の表はそれぞれのパッケージ管理方法のメリットとデメリットのまとめです。

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

cabal-install

公式リポジトリから cabal-install をインストールしてください。

ノート: cabal-install パッケージには "cabal" コマンドラインユーティリティが含まれています。一方、Cabal は "Cabal" ライブラリを提供するパッケージであり、cabal-install と stack の両方が使用します。

準備

パスを指定しないでインストールした実行可能ファイルを実行するには、cabal のバイナリフォルダ ~/.cabal/bin を $PATH 変数に追加する必要があります。シェルの設定ファイルに以下の行を記述することで追加できます (bash の場合 ~/.bashrc、zsh の場合 ~/.zshrc): 

PATH=$PATH:~/.cabal/bin

cabal sandbox の中で実行したい場合: 

PATH=$PATH:.cabal-sandbox/bin

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

$ cabal update

$ # Dynamic linking
$ cabal install --disable-library-vanilla --enable-shared --enable-executable-dynamic <pkg>

$ # Static linking (requires ghc-static and ghc-pristine)
$ cabal install --with-compiler=/usr/share/ghc-pristine/bin/ghc <pkg>

-j を追加することで並列コンパイルができます。また、--global フラグを使うことでシステム全体にパッケージをインストールすることもできますが、これは非推奨です。ユーザーごとのインストールでは、全てのファイルは ~/.cabal に配置されライブラリは ~/.ghc に登録されるので、フォルダを削除することで簡単にクリーンアップすることができます。システム全体にインストールすると、ファイルがファイルシステムに散らばってしまい管理するのが難しくなります。

サンドボックス

警告: サンドボックスは廃止予定であり、Cabal 3.4 で取り除かれます。

Cabal のサンドボックスは矛盾のないローカルパッケージデータベースと環境を提供します (Python における virtual-env あるいは Ruby における rvm に似ています)。カレントディレクトリにサンドボックスを作成するには: 

$ cabal sandbox init

削除するには: 

$ cabal sandbox delete

カレントディレクトリにサンドボックスが存在する場合、デフォルトで cabal はその環境を使用します。#パッケージのインストールと同じ手順でインストールができます。別のサンドボックスを使いたい場合、cabal exec "$SHELL" を実行してサンドボックスのシェルを起動します。そこからディレクトリを移動しても cabal は指定されたサンドボックスを使用します。また、cabal に --sandbox-config-file=/somewhere/cabal.sandbox.config フラグを渡して使うことも可能です。

cabal のサンドボックスの中で実行ファイルを実行するには、

PATH=$PATH:$PWD/.cabal-sandbox/bin

を設定するか、cabal exec "$SHELL" でローカルシェルを起動する必要があります。

パッケージの削除

パッケージの削除を簡単に行う方法はありません。Cabal には削除機能がありません。

サンドボックスにインストールした場合、他のサンドボックスへの影響を及ぼさずに削除することができます。

zsh の自動補完を使うことで haskell パッケージを探し出しやすくなります。

Haskell のパッケーシステム全体を修正・再インストールしたい場合、~/.cabal と ~/.ghc を削除してスクラッチからインストールしなおしてください。GHC をアップグレードした場合に必要になります。

開発ツール

ツール

haskell-language-server

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

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

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

ghcid

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

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

ghcup-hs-binAUR パッケージをインストールしてください。あるいは、公式の インストール手順 に従うか、手動で 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-staticAUR パッケージをインストールします。あるいは、公式の インストール手順 に従うか、スタックバイナリ を手動でダウンロードして、それをあなたの $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 ドキュメント を参照してください。

Nix

この記事またはセクションは加筆を必要としています。
理由: I cannot offer a good enough overview, due to no experience with it (議論: トーク:Haskell#)

ヒントとテクニック

静的リンク

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

stack-static

stack-staticAUR パッケージをインストールします。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-binAUR は、haskell-hpack の代わりに静的にリンクされた (haskell-* 依存関係がないことを意味します) を提供します。プリコンパイルされているため、make 依存関係は必要ありません。

ghcup

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

参照

「https://wiki.archlinux.jp/index.php?title=Haskell&oldid=33139」から取得