Haskell

提供: ArchWiki
2020年8月22日 (土) 00:40時点におけるShota (トーク | 投稿記録)による版 (→‎サンドボックス: Cabal 3.4 からサンドボックス機能の廃止 （英語版を反映))
ナビゲーションに移動 検索に移動

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

ArchHaskell リポジトリ

詳細は ArchHaskell を見て下さい。

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 をアップグレードした場合に必要になります。

stack

Stack は依存関係の解決よりも自動的に精選された、矛盾のないパッケージに焦点を置いたビルドツールです。Stackage スナップショットの中で共存させる限り、バージョンの衝突に気をつかうことなくパッケージを簡単にインストールすることができます。Stack は stack, stack-staticAUR, stack-binAUR パッケージでインストールできます。後者は静的リンクライブラリを提供し、様々な haskell-* 依存パッケージを必要としません。詳しくは § Install/upgrade # Arch Linux を参照。

参照

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