1. Haskell‎ > ‎

01. 環境構築

Windows環境で実施しています。

目次

  1. 1 stackによる環境構築
    1. 1.1 stackのインストール
    2. 1.2 プロジェクトの管理
      1. 1.2.1 プロジェクトの作成
      2. 1.2.2 プロジェクトのセットアップ
      3. 1.2.3 ソースコードの記述
      4. 1.2.4 ビルド
      5. 1.2.5 実行
      6. 1.2.6 パッケージの追加
      7. 1.2.7 パッケージの追加(resolverに含まれていない場合)
      8. 1.2.8 .cabalとstack.yamlの違いとは
      9. 1.2.9 リンカで"に対する定義されていない参照です"が発生する場合
      10. 1.2.10 Cabalのアップデート
    3. 1.3 ghciを起動する
    4. 1.4 ghcでコンパイル
    5. 1.5 アンインストール
    6. 1.6 参考
  2. 2 (以下は古い記事です)
  3. 3 2つの選択肢
  4. 4 Compiler and base libraries
    1. 4.1 (1)インストール
    2. 4.2 (2)最新パッケージリストの取得
  5. 5 Haskell Platform
    1. 5.1 (1)Haskell Platformのインストール
    2. 5.2 (2)最新パッケージリストの取得
    3. 5.3 (3)cabal-installの最新化
    4. 5.4 (4)"ghc.exe: panic!"対応(Windows/Cabal 1.18の場合のみ)
  6. 6 アンインストール
    1. 6.1 Haskell Platformのアンインストール
    2. 6.2 ファイルの手動削除
  7. 7 sandboxによる、ワークスペース単位でのパッケージ管理
    1. 7.1 cabal sandbox
    2. 7.2 sandbox下でのコンパイル
    3. 7.3 sandbox下でのHaddock
    4. 7.4 sandbox下の実行ファイル
    5. 7.5 参考
  8. 8 GHCでコンパイル
    1. 8.1 ソースファイルの作成
    2. 8.2 コンパイル
    3. 8.3 実行
  9. 9 cabal-installのinternal error
  10. 10 EclipseFP
    1. 10.1 インストール
    2. 10.2 Rebuilding local database
    3. 10.3 使用するCabalの選択
    4. 10.4 プロジェクト作成
    5. 10.5 実行
  11. 11 GHC単体のインストール(古い記事です)
    1. 11.1 (1)Haskell Platformのインストール
    2. 11.2 (2)MSYS2のインストール
    3. 11.3 (3)GHCのインストール
    4. 11.4 (4)cabal-installのインストール
    5. 11.5 トラブルシューティング
      1. 11.5.1 networkパッケージのインストールに失敗する。
      2. 11.5.2 cabal.exeのリンクで失敗する。




stackによる環境構築


stackとは、ビルドするプロジェクトに最適なGHC(Haskellのコンパイラ)やパッケージを管理するツールです。
GHCやパッケージのダウンロードから面倒見てくれますし、今後のスタンダードになりそうなので、始めての方もstackで環境構築したほうが良さそうです。
stackがパッケージのバージョンを管理してくれるので、cabal sandboxを自前で構築することも無くなります。


stackのインストール


install and upgrade pageの"Windows"の"Installer"から、環境に合わせたインストーラ(32/64bit)をダウンロードし、実行します。

なお、前のバージョンでは手動設定してた環境変数STACK_ROOTが、インストール時のオプションで作成できるようになっています。しかも、デフォルトでONになっています。


プロジェクトの管理


プロジェクトの作成


stackでアプリケーションを作成する場合、アプリケーション毎にプロジェクトを作成することをオススメします。
プロジェクト内であれば、好き勝手にパッケージをインストールしても、プロジェクト外に悪影響を与えることはありません。

コマンドstack newで、新しいプロジェクトを作成します。下記はプロジェクト名stack-exampleで作成します。
C:\Haskell>stack new stack-example


実行すると、プロジェクトのフォルダとして、フォルダstack-exampleが作成されます。以降の作業はプロジェクトのフォルダ内で行います。
プロジェクト名の後に、作成するプロジェクトのテンプレートを指定することもできます。今回のように省略した場合は、テンプレート"new-template"でプロジェクトが作成されます。


プロジェクトのセットアップ


通常は、プロジェクトを作成した直後に、プロジェクトのフォルダでコマンドstack setupを実行して、プロジェクトのセットアップを行います。
GHCのインストールが行われていない場合は、このタイミングでインストールされます(そこそこ時間が掛かります)。
C:\Haskell\stack-example>stack setup


デフォルトのresolver以外を使用したい場合等は、コマンドstack setupを実行する前にstack.yamlを編集して、その後コマンドを実行してください。


ソースコードの記述


テンプレートnew-templateでプロジェクトを作成した場合、ソースファイルは下記のように分割されて作成されます。
※アプリケーションの実行に直接関係無いSetup.hsは除く
\
|--app\
|    |--Main.hs
|
|--src\

|    |--Lib.hs
|
|--test\

     |--Spec.hs


src/Lib.hs
module Lib
    ( someFunc
    ) where

someFunc :: IO ()
someFunc = putStrLn "someFunc"


app/Main.hs
module Main where

import Lib

main :: IO ()
main = someFunc


test/Spec.hs
main :: IO ()
main = putStrLn "Test suite not yet implemented"


テンプレートnew-templateで作成したプロジェクトの、実行時のエントリポイントはapp/Main.hsの関数mainです。
関数mainから、src/Lib.hsにある関数someFuncを呼び出すようになっています。

プロジェクトの定義で、src/Lib.hsはライブラリ用のソースファイル、app/Main.hsは実行可能ファイル用のソースファイルとなっています。test/Spec.hsは単体テスト記述用のソースファイルです。
基本的な使い分けは、殆どの関数や定義はsrc/Lib.hs等のライブラリのソース側に記述し、app/Main.hs等の実行可能ファイルのソース側には、コマンドライン引数の取得等、実行環境とライブラリ間の橋渡しを記述する程度にします。
なお、単体テストの対象となるのはライブラリ側のみです。


ビルド


コマンドstack buildで、アプリケーションのビルドを行います。
C:\Haskell\stack-example>stack build



実行


ビルド後のメッセージで、下記の位置に実行可能ファイルが作成されたことが通知されます。
Installing executable(s) in
[実行ファイルの作成先]


もちろん、ここの実行可能ファイルを直接起動しても良いのですが、そこまで移動するのも面倒なので、通常はコマンドstack execを用います。
execの後に指定するのは実行ファイル名ですが、テンプレートnew-templateの場合、[プロジェクト名]-exeとなっています。
C:\Haskell\stack-example>stack exec stack-example-exe



パッケージの追加


さて、stackのキモである、パッケージ管理についてです。
従来はcabal installコマンドを用いていましたが、stackで環境構築した場合は使わないようにしておきましょう。

例えば、下記のソースでは、パッケージtextのモジュールであるData.Text.IOを参照しています。
※Haskellのソースで日本語を扱う場合は、ファイルをUTF-8で保存してください。

src/Lib.hs
{-# LANGUAGE OverloadedStrings #-}

module Lib
    ( someFunc
    ) where


import qualified Data.Text.IO as T


someFunc :: IO ()
someFunc = T.putStrLn "ちわっす"


何もせずにstack buildコマンドを実行した場合、「そんなモジュール無ぇよ」とエラーとなります。
一方で「パッケージtextを.cabalファイルのbuild-dependsに追加してみ?」と、対処法を教えてくれます。
C:\Haskell\stack\stack-example>stack build
(略)
    Could not find module ‘Data.Text.IO’
(略)
    Perhaps you need to addtextto the build-depends in your .cabal file.


ということで、.cabalファイルのbuild-dependsに、パッケージtextを追加します。
このときに、パッケージのバージョン制約を記述してはいけません。stack登場前には、バージョン制約として、ビルドに利用可能なバージョンの範囲をここで明記していましたが、そのへんをstack.yamlに分離したのが、stackの画期的なところです。
※むしろ、何でbaseには制約を記述しているのかがわからない…

stack-example.cabal
library
  hs-source-dirs:      src
  exposed-modules:     Lib
  build-depends:       base >= 4.7 && < 5
                     , text
  default-language:    Haskell2010


Lib側にパッケージを追加するので、セクションlibraryのbuild-dependsに追加します。
これでstack buildを実行すれば、パッケージtextのダウンロードから自動で行ってくれます。


パッケージの追加(resolverに含まれていない場合)


詳しい話は割愛して、通常良く使うパッケージはLTS Haskellに含まれていて、上記の手順で追加できます。
resolver(通常はLTS Haskell)に含まれていないパッケージを使う場合は、上記に加えてstack.yamlを編集する必要があります。

例えば、OpenGLの低レベルバインディングである、OpenGLRawはLTS Haskellに含まれていません。
これを.cabalに追加してみます。
なお、このときでもバージョン制約を記述してはいけません。
  build-depends:       base >= 4.7 && < 5
                     , OpenGLRaw


stack buildコマンドを実行すると「そんなパッケージ知らん」とエラーになります。
一方で「stack.yamlのextra-depsに、OpenGLRaw-2.6.0.0を追加したらどうよ?」と対処法を教えてくれます。
※stackは、エラーメッセージが親切なのが有り難い
C:\Haskell\stack\stack-example>stack build
Setting codepage to UTF-8 (65001) to ensure correct output from GHC
While constructing the BuildPlan the following exceptions were encountered:

--  While attempting to add dependency,
    Could not find package OpenGLRaw in known packages

--  Failure when adding dependencies:
      OpenGLRaw: needed (-any), not present in build plan (latest is 2.6.0.0)
    needed for package: stack-example-0.1.0.0

Recommended action: try adding the following to your extra-deps in C:\Haskell\stack\stack-example\stack.yaml
- OpenGLRaw-2.6.0.0


ということで、stack.yamlファイルのextra-depsに、メッセージの通りの記述を追加します。
extra-deps:
- OpenGLRaw-2.6.0.0


stack buildを実行すると、パッケージのダウンロード/インストールが行われて、ビルドが完了します。


.cabalとstack.yamlの違いとは


最初にstackを見たときに「なぜ依存パッケージの指定を、.cabalとstack.yamlの2つに分けるの?」と悩むこともあるかと思います。
結論から言えば、
  • .cabal : パッケージのバージョンを考慮せずに、依存パッケージの指定を行う。
  • stack.yaml : .cabalで指定されたパッケージの、実際に用いるバージョンの指定を行う。
という役割の分担です。プログラミングでも良くある「仕様」と「実装」のような関係です。

stack登場前は、ビルド可能なパッケージのバージョンの組み合わせを、パッケージ利用者側が意識する必要がありました。
そうしない場合は、あるパッケージのバージョンを上げると、他の依存パッケージがビルドできなくなるといった、いわゆる依存性地獄(dep hell)が発生する場合がありました。

組み合わせを利用者側が意識しなくても済む様に出来たのがStackage/LTS Haskellです。Stackage/LTS Haskellは、ビルド成功が保証された、パッケージのバージョンの組み合わせのスナップショットです。
パッケージ利用者は、バージョンを指定せずに、利用したいパッケージを.cabalで指定します。そして、自分が利用したいパッケージのバージョンを含むStackage/LTS Haskellのバージョンを、stack.yamlのresolverとして指定すれば、自分が意識しない依存パッケージのバージョンについても、適切な組み合わせが提供されます。

Stackage/LTS Haskellに含まれないパッケージについても、.cabalファイルではバージョン指定せずに、stack.yamlでバージョンを指定します。

.cabalは、バージョンを意識せずに、利用したい依存パッケージを指定するためのものであり、stack.yamlは、resolverとextra-depsで、.cabalファイルに指定されたパッケージのバージョンを解決するためのファイルです。


リンカで"に対する定義されていない参照です"が発生する場合


リンカで"~に対する定義されていない参照です"というエラーが発生する場合は、参照先のライブラリ側で、必要なモジュールがexposed-modulesに存在しない可能性があります。
公開するジュールは、サブモジュールも含めてexposed-modulesに記述します。
  exposed-modules:     Lib
                     , Lib.Sub1
                     , Lib.Sub2



Cabalのアップデート


GHCのグローバルパッケージに存在するCabalよりも、resolverが依存するCabalが新しい場合に、パッケージのビルドに失敗する場合があります。

例: GHCのCabalが1.24.0.0で、LTS HaskellのCabalが1.24.1.0の場合に発生するビルドエラー
    C:\Users\foo\AppData\Local\Temp\stack5512\glib-0.13.4.1\Setup.hs:8:29: error:
        「 Couldn't match expected type ‘Distribution.Simple.UserHooks.UserHooks’
                      with actual type ‘Cabal-1.24.1.0:Distribution.Simple.UserHooks.UserHooks’
          NB: ‘Cabal-1.24.1.0:Distribution.Simple.UserHooks.UserHooks’
                is defined in ‘Distribution.Simple.UserHooks’
                    in package ‘Cabal-1.24.1.0’
              ‘Distribution.Simple.UserHooks.UserHooks’
                is defined in ‘Distribution.Simple.UserHooks’
                    in package ‘Cabal-1.24.0.0’
        「 In the first argument of ‘defaultMainWithHooks’, namely
            ‘gtk2hsUserHooks’
          In the expression: defaultMainWithHooks gtk2hsUserHooks
          In an equation for ‘main’:
              main = defaultMainWithHooks gtk2hsUserHooks


その場合は、下記コマンドでグローバルパッケージのCabalをアップデートすることを試してみてください。
C:\Haskell\stack-example>stack setup --upgrade-cabal



ghciを起動する


stackで環境構築した場合、ghciはコマンドstack ghciで起動します。
C:\Haskell\stack-example>stack ghci



ghcでコンパイル


ちょっとしたプログラムを試すのに、毎回プロジェクトを作成するのも面倒です。そのために、ghcを起動するコマンドも用意されています。
C:\Haskell\stack-example>stack ghc Other.hs


但し、プロジェクト内で作業するのがstackのセオリーなので、作業用プロジェクトを作成した上で、その中で個々のソースをコンパイルしたほうが良いでしょう。

ghcオプションを指定する場合は、--の後ろに指定します。
C:\Haskell\stack-example>stack ghc -- version



アンインストール


アンインストールは、通常のWindowsアプリケーションと同じように、コントロールパネルから行います。
処理完了後、下記のフォルダが残っている場合は手動で削除します。
  • %HOME%\AppData\Local\Programs\stack
  • %HOME%\AppData\Roaming\local\bin
また、環境変数STACK_ROOTを設定していた場合、該当フォルダ(デフォルトはC:\sr)も削除します。


参考


stack/GUIDE.md at release · commercialhaskell/stack · GitHub
Haskellのビルドツール"stack"の紹介 - Qiita
Stackでやる最速Haskell Hello world! (GHCのインストール付き!) - Qiita
もうcabal hellは怖くない、Stackを使ってみるよ! - Creatable a => a -> IO b




(以下は古い記事です)



2つの選択肢


2015/04現在、Haskell環境構築方法として、下記の2つの選択肢があります。
Downloads - haskell.org
  1. Compiler and base libraries
  2. Haskell Platform
1の場合は、最低限のライブラリしかインストールされない(mtlすら入らない)ので、それなりにパッケージのインストール作業が必要になります。その分、常に最新のコンパイラやライブラリ環境が利用できます。
2の場合は、GHCコンパイラや基本ライブラリの他、一般的によく使われるパッケージもまとめてインストールされるので、慣れない方はこちらをインストールしたほうが良いかと思います。但し、極力枯れたバージョンのコンパイラやパッケージで構成される傾向があるので、最新の環境を利用したい場合には、結局1と同じ手間を掛けることになります。


Compiler and base libraries


上記Downloads - haskell.orgのページで、プラットフォームに応じたインストーラをダウンロードしてください。
Win版の場合は、下記のページで、より最新のバージョンのインストーラが入手できます。
Minimum GHC Installer - FP Complete - GitHub

(1)インストール


入手したインストーラを実行します。
途中の"Add programs to PATH"と"Add switcher to PATH"については、両方ともチェックをONにして構いません。

(2)最新パッケージリストの取得


cabal-installでパッケージ管理を行う第一歩として、最新のパッケージリストを更新します。updateコマンドを実行します。
C:\>cabal update


Haskell Platform


(1)Haskell Platformのインストール


The Haskell Platform
からインストーラをダウンロードして実行します。

インストールされる、主なコンポーネントは下記の通りです。
 GHCHaskellコンパイラ
 cabal-installパッケージ管理ツール(Cabalのフロントエンド)


(2)最新パッケージリストの取得


cabal-installでパッケージ管理を行う第一歩として、最新のパッケージリストを更新します。updateコマンドを実行します。
C:\>cabal update


(3)cabal-installの最新化


updateコマンドを実行後、cabal-install自体が最新では無い場合
Note: there is a new version of cabal-install available.
To upgrade, run: cabal install cabal-install
と表示されます。

まずは、cabal --versionで現状のバージョンを確認します。
C:\>cabal --version
cabal-install version 1.18.0.5
using version 1.18.1.3 of the Cabal library


次に、updateコマンドの指示に従って、cabal installコマンドで、最新のcabal-installをインストールします。
C:\>cabal install cabal-install

何だかいろいろ頑張った後にコマンドが完了しました。では、バージョンを確認してみましょう。
C:\>cabal --version
cabal-install version 1.18.0.5
using version 1.18.1.3 of the Cabal library


…変わっていない。

そういえば、cabal installコマンドの最後のメッセージに
Installing executable(s) in C:\Users\[ユーザ名]\AppData\Roaming\cabal\bin

なんて表示されていました。

実は、最新の実行モジュールcabal.exeが、表示のディレクトリに作成されたものの、PATHの優先順位が
  1. C:\Program Files (x86)\Haskell Platform\2012.4.0.0\lib\extralibs\bin\ (現在実行中の、古いcabal.exeがある)
  2. C:\Users\[ユーザ名]\AppData\Roaming\cabal\bin\ (作成された最新のcabal.exeがある)
となっているために、installコマンドを実行しただけでは相変わらず古い方が優先されてしまいます。

なぜこんな事になるかというと、1のパスはシステム環境変数のPATHに設定されているのに対し、2のパスはユーザ環境変数のPATHに設定されているためです。
一度2のパスにcabal.exeのインストールが完了すれば、1のパスに存在する古いcabal.exeは不要なので、システム環境変数のPATHから、1のパスを削除します。

で、その結果
C:\>cabal --version
cabal-install version 1.18.0.2
using version 1.18.1.2 of the Cabal library
無事、アップグレードできました。


(4)"ghc.exe: panic!"対応(Windows/Cabal 1.18の場合のみ)


現在のHaskell Platform 2013.2.0.0に同梱されているGHC 7.6.3には、
#7056 (GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve') – GHC
のために、最新のCabal 1.18ではビルドできないパッケージが幾つかあります。

次のHaskell Platform 2013.4.0.0では、この問題をCabal側で回避する修正が入る予定です。
が、それまでの応急処置として、Cabal 1.18にアップグレードした後に、
C:\Users\[ユーザ名]\AppData\Roaming\cabal\configファイルの
-- library-for-ghci: True

のコメントアウトを外して、

library-for-ghci: True

と有効化しておきます。




アンインストール


アンインストールですが、気をつけないとキレイにアンインストールされず、再インストール時に昔のファイルが邪魔をします。以下はWindows版です。

Haskell Platformのアンインストール


通常のアプリケーションと同様に、[コントロールパネル]-[プログラムと機能]から、Haskell Platformをアンインストールします。


ファイルの手動削除


cabalで導入したパッケージのファイルは、Haskell Platformのアンインストールでは削除されないので、手動で削除します。
削除するのは
  • C:\Users\[ユーザ名]\AppData\Roaming\cabal
  • C:\Users\[ユーザ名]\AppData\Roaming\ghc
の2つのディレクトリです。




sandboxによる、ワークスペース単位でのパッケージ管理


cabal sandbox


cabal-install 1.18より、sandboxによる、独立したパッケージ管理が可能になりました。

sandboxを用いない場合は、インストールしたパッケージは(通常は)OSユーザ単位での管理となります。そのため、全く異なる目的のアプリケーション同士を導入する際にも、同じパッケージ管理下にインストールされることになり、それらの依存パッケージが衝突を起こすと、いわゆる依存性地獄(dependency hell)が起こってしまいます。

sandboxを用いることにより、目的に応じてパッケージ管理を独立させることが可能になりました。
基本的には、sandboxを用いることをオススメします。

注意事項として、パッケージcabal-installを更新するつもりで、sandbox環境でコマンドcabal install cabal-installを実行すると、グローバル環境のcabal-installの更新ではなく、sandbox環境にパッケージcabal-installがインストールされてしまいます。
パッケージcabal-installの更新は、sandbox環境外で実行してください。


具体的な運用方法はいろいろありますが、一例として下記の方法をご紹介します。

まず、独立したパッケージ管理を行う単位を「ワークスペース」とし、それぞれのディレクトリを作成します。
※ルートは任意の位置でOKです。
\
|--OpenGL\ : OpenGL関係の開発を行うワークスペースディレクトリ
|
|--Text\ : テキスト処理関係の開発を行うワークスペースディレクトリ



各ワークスペース内で、アプリケーションを作成する単位を「プロジェクト」として、それぞれのディレクトリを作成します。
同じワークスペース内のプロジェクトでは、同じパッケージ管理を共有します。
\
|--OpenGL\
|    |--OpenGLApp1\ : OpenGLのアプリケーション1開発プロジェクトディレクトリ
|    |--OpenGLApp2\ : OpenGLのアプリケーション2開発プロジェクトディレクトリ
|
|--Text\

     |--TextApp1\ : テキスト処理のアプリケーション1開発プロジェクトディレクトリ
     |--TextApp2\ : テキスト処理のアプリケーション2開発プロジェクトディレクトリ

ワークスペースディレクトリをカレントにして、cabal sandbox initコマンドを実行して、ワークスペース用のsandboxを作成します。

OpenGLワークスペースの場合
\OpenGL>cabal sandbox init

結果は下記の通りになります。
.cabal-sandboxディレクトリが作成されます。
\
|--OpenGL\

|    |--.cabal-sandbox\ : OpenGLワークスペースの共有sandbox
|    |    |--i386-windows-ghc-7.6.3-packages.conf.d\ : パッケージデータベース
|    |
|    |--OpenGLApp1\
|    |--OpenGLApp2\
|
|--Text\

     |--.cabal-sandbox\ : Textワークスペースの共有sandbox
     |    |--i386-windows-ghc-7.6.3-packages.conf.d\ : パッケージデータベース
     |
     |--TextApp1\
     |--TextApp2\


各プロジェクトでワークスペースのsandboxを参照するように設定します。各プロジェクトディレクトリをカレントにして、cabal sandbox initコマンドを実行します。

OpenGLApp1プロジェクトの場合
\OpenGL\OpenGLApp1>cabal sandbox init --sandbox ..\.cabal-sandbox
--sandboxオプションで、参照するsandboxを指定します。
これにより、ワークスペース内ではパッケージ管理が共通化されつつ、ワークスペース間では独立されます。

結果は下記の通りになります。
sandboxを参照する、cabal-installの設定ファイルが作成されます。
\
|--OpenGL\

|    |--.cabal-sandbox\
|    |    |--i386-windows-ghc-7.6.3-packages.conf.d\
|    |
|    |--OpenGLApp1\
|    |    |--cabal.sandbox.config : cabal-installの設定ファイル
|    |
|    |--OpenGLApp2\
|    |    |--cabal.sandbox.config : cabal-installの設定ファイル
|
|--Text\

     |--.cabal-sandbox\
     |    |--i386-windows-ghc-7.6.3-packages.conf.d\
     |
     |--TextApp1\
     |    |--cabal.sandbox.config : cabal-installの設定ファイル
     |
     |--TextApp2\
 
    |    |--cabal.sandbox.config : cabal-installの設定ファイル


後は、設定ファイルがある場所で、パッケージのインストール等、通常のcabal-installのコマンドを実行してください。
実行結果は、同じワークスペースのプロジェクト間で共有されます。
逆に、それ以外の場所で実行すると、sandboxではなくて従来のcabal-installの動き通り、ユーザ単位のプロジェクト管理下に結果が反映されるので注意。


sandbox下でのコンパイル


sandboxにインストールしたパッケージを用いて、GHCでコンパイルする場合には、sandbox内のパッケージデータベースを指定する必要があります。
\OpenGL\OpenGLApp1>ghc -package-db ..\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d [ソースファイル名]


バッチファイルを作っておいたほうが良いでしょう。
ファイル名をghc.cmdとしておけば、通常のghc.exeと同じ感覚でタイピングできます。
ghc.exe -package-db ..\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d %1 %2 %3 %4 %5 %6 %7 %8 %9


cabal buildの場合は設定ファイルを見て判断してくれるので、通常通りでOKです。


sandbox下でのHaddock


haddockを実行する場合も、同様にパッケージデータベースを指定する必要があります。--optghcオプションで、ghcコマンドの場合と同じオプションを指定します。
ghcコマンドと同様に、バッチファイルを作っておきましょう。
haddock.exe --optghc="-package-db ..\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d" %1 %2 %3 %4 %5 %6 %7 %8 %9



sandbox下の実行ファイル


例えば、yesod-binのような、コマンドの実行ファイルを生成するパッケージの場合、実行ファイルもsandbox下に配置されます。
.cabal-sandbox\
    |-bin\ : 実行ファイルの格納ディレクトリ


当然実行するには、そのディレクトリに対してパスを通しておく必要があります。

システムの環境変数PATHに追加する方法もありますが、せっかくsandboxとして隔離させているので、ローカルの環境変数に追加してコマンドを起動する下記バッチファイルを作成しておくのも手です。
ファイル名を[実行ファイル名].cmdとしておけば、通常の[実行ファイル名].exeと同じ感覚でコマンドを起動できます。

下記はyesod.exeの場合
yesod.cmd
echo off
setlocal
set PATH=[sandboxの実行ファイルの格納ディレクトリ(フルパス)];%PATH%
yesod.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
endlocal


バッチファイル内での実行ファイルの拡張子は必ず付加しておいてください。さもないと、バッチファイルに対して、皆様お馴染みの再帰呼び出しになってしまいますので…。
あと、ディレクトリをフルパスにしておくのは、プロジェクトの下のサブプロジェクトのような、階層が深くなった場合でも同じバッチファイルを使いまわせるようにするためです。

ちなみに、実行ファイルのショートカットにしないのは、コマンドが、同じディレクトリにある別のコマンドを呼び出す場合があるためです。それに対処するために、PATHを設定しています。


参考


An Introduction to Cabal sandboxes
2013年8月現在のHaskell開発環境 - maoeのブログ
cabal 1.18 が提供するサンドボックスの小技 - あどけない話




GHCでコンパイル


ソースファイルの作成


テキストエディタ等で、ソースファイルを作成します。通常、拡張子は.hsです。

Hello.hs
main :: IO ()
main = putStrLn "Hello, World!"



コンパイル


あとは、ghcコマンドでコンパイルです。
C:\Haskell>ghc Hello.hs


実行


Hello.exeが作成されますので、実行してみます。
C:\Haskell>Hello
Hello, World!




cabal-installのinternal error


cabal-installコマンド発行時に、時々
cabal: internal error when reading package index: could not read tar file
entryThe package index or index cache is probably corrupt. Running cabal
update might fix it.


というエラーが出て、何もできなくなる場合があります。そういう時は、
C:\Users\[ユーザ名]\AppData\Roaming\cabal\packages\hackage.haskell.org\00-index.cache
を削除して、cabal updateコマンドを実行すれば回復します。




EclipseFP


EclipseFPは、EclipseのHaskell環境プラグインです。

インストール


※Haskell Platformがインストール済みであるのが前提です。

更新サイト
http://eclipsefp.sf.net/updates

からインストールを行います。

Eclipse再起動後にダイアログが表示されます。

いろいろパッケージをインストールするよ、とのことなので、言われるがままに[Install optional helper executables]と[Install for current user only]をonにしておいて、[Install]をクリックします。このあと、時間が掛かるので一休み…。

以降も
 Hoogle data not present
だの
 Use Hackage database
だの、ダイアログが表示されますが、とりあえず[Yes]を選択しておきます。


Rebuilding local database


EclipseFPのFAQの"Why is EclipseFP sometimes so slow to start?"に記載がありますが、
ワークスペースで作業を開始する度に、"Rebuilding local database"というBackground Progessメッセージとともに、コンポーネントのデータベースの再構築が実行されます。
初回は結構長い時間掛かりますが、一度完了すれば、次回以降のワークスペース起動時には、再構築は早めに終わります。
逆に、これが終わらないとプロジェクトの削除が出来ないなど、何かと面倒くさいです。
ワークスペースを切り替えてもEclipseが再起動しない現象が起こったら、これが原因なので、しばらく待ってください。再構築が終わればEclipseの再起動が始まります。


使用するCabalの選択


この時点で、複数のバージョンのCabalがインストールされてしまっている場合があるので、その中から使用するCabalを選択します。
メニューより[Window]-[Preferences]、ツリーの[Haskell]-[Helper executables]で、[Installed Cabal Implementations]に、インストール済みのCabalが表示されますので、最新バージョンのCabalを選択しておきます。
推奨は、Haskell Platformのインストール後の、cabal install cabal-installでインストールしたバージョンでしょうか。


プロジェクト作成


インストールが完了すれば、プロジェクトで[Haskell Project]が選択可能になるので、Haskellプロジェクトを作成します。
srcフォルダに作成されているMain.hsが、実行されるソースファイルです。コンパイルは自動で行われます。
下記のように書き換えてみます。

Main.hs
module Main where

main :: IO ()
main = putStrLn "Hello, World!"


実行


プロジェクトのルートのコンテキストメニューから[Run As]-[Run Haskell Application]で、Main.hsの内容が実行されます。




GHC単体のインストール(古い記事です)


※2015/04現在、GHCのインストーラが提供されるようになりましたので、上記"Compiler and base libraries"を参照してください。本記事は参考のため残しています。

場合によっては、Haskell Platformで提供されているものよりも新しいバージョンのGHCを使いたい場合があります。
多少手間なので、GHC単体でインストールするのは、特に必要な場合のみにしておいたほうが吉かと。


(1)Haskell Platformのインストール


cabal-installのバイナリが欲しいだけですが、公式サイトに上がっているWindows版の最新のバイナリ(1.20.0.2)が壊れているっぽいので、渋々Haskell Platformのcabal-installを用いることにします。
前節の手順でHaskell Platformをインストールします。

なお、GHC 7.8をインストールしても、Haskell Platformの環境とは競合しないので、既にHaskell Platformを導入済みの人も安心してGHC 7.8をインストールできる、と思います…。


(2)MSYS2のインストール


一部のパッケージのインストールにMSYS2が必要になるため、前もってインストールしておきます。

MSYS2 - SourceForge.net

パッケージの場所は下記の通りです。
32-bit版
64-bit版

なお、パッケージ展開やフォルダ移動等のファイル操作の際、ノートン等のセキュリティソフトが、MSYS2に含まれているuname.exeをセキュリティリスクとして削除する場合があります。
uname.exeが無いと、この後のnetworkパッケージのインストールに失敗します。
この場合は、一時的にセキュリティソフトのファイル監視を無効化して、MSYS2をインストール後に、MSYS2のフォルダをファイル監視対象外に設定後、ファイル監視を再び有効化します。
※このあたりの操作によるリスクについては、自己責任でお願いします。

パッケージ展開後のフォルダ位置ですが、非ASCII文字や空白を含むフォルダ名には配置してはダメなので、おとなしくルートに置いておきます。

32-bit版の場合
C:\
|--msys32\
|    |--bin\
|    |--etc\
|    …


後は、binフォルダ(上記の場合、C:\msys32\bin)を環境変数PATHに追加します。


(3)GHCのインストール


GHCのバイナリパッケージをダウンロードします。
32-bit版と64-bit版があるので注意。

パッケージ展開後のフォルダ位置はどこでも良いです。下記は32-bit版をC:\Program Files (x86)に配置した例です。
C:\
|--Program Files (x86)\
|    |--ghc-7.8.2\
|        |--bin\
|        |--doc\
|        |--lib\
|        |--mingw\
|        |    |--bin\
|        |    …
|        …


後 は、binフォルダ(上記の場合、C:\Program Files (x86)\ghc-7.8.2\bin)と、mingwのbinフォルダ(上記の場合、C:\Program Files (x86)\ghc-7.8.2\mingw\bin)を環境変数PATHに追加します。
Haskell Platform導入済みの場合は、それらのパスの前に追加してください。


(4)cabal-installのインストール


cabal-installをインストールします。どちらかと言うと、GHC 7.8用のパッケージデータベースを構築するのが目的です。

注 意するのは、WindowsのコマンドプロンプトやMSYS2内のmsys2_shell.batのシェルで行うのではなく、MSYS2内の mingwxx_shell.batのシェル(32-bit版の場合、C:\msys32\mingw32_shell.bat)でcabal installコマンドを実行してください。
cabal install cabal-install


依存する全パッケージを1からビルドするため時間が掛かるので、気長に待ちましょう。


以上の手順で、GHC 7.8が利用可能になるはずです。
ここまでくれば、Windowsのコマンドプロンプトでも利用可能です、多分。


トラブルシューティング


networkパッケージのインストールに失敗する。


下記のようなエラーで失敗する場合
This script, last modified 2014-03-23, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
  http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <config-patches@gnu.org> in order to provide the needed
information to handle your system.

config.guess timestamp = 2014-03-23

uname -m = unknown
uname -r = unknown
uname -s = unknown
uname -v = unknown

/usr/bin/uname -p =
/bin/uname -X     =

hostinfo               =
/bin/universe          =
/usr/bin/arch -k       =
/bin/arch              =
/usr/bin/oslevel       =
/usr/convex/getsysinfo =

UNAME_MACHINE = unknown
UNAME_RELEASE = unknown
UNAME_SYSTEM  = unknown
UNAME_VERSION = unknown
configure: error: cannot guess build type; you must specify one
Failed to install network-2.5.0.0
cabal.exe: Error: some packages failed to install:
HTTP-4000.2.17 depends on network-2.5.0.0 which failed to install.
cabal-install-1.20.0.2 depends on network-2.5.0.0 which failed to install.
network-2.5.0.0 failed during the configure step. The exception was:
ExitFailure 1


MSYS2のuname.exeが、セキュリティソフトによって削除されている可能性があります。(2)MSYS2のインストールを参照して、MSYS2のインストールをやり直してください。


cabal.exeのリンクで失敗する。


下記のようなエラーで失敗する場合
Linking dist\build\cabal\cabal.exe ...
Warning: resolving _shutdown by linking to _shutdown@8
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving _htons by linking to _htons@4
Warning: resolving _htonl by linking to _htonl@4
Warning: resolving _inet_addr by linking to _inet_addr@4
Warning: resolving _connect by linking to _connect@12
Warning: resolving _ntohs by linking to _ntohs@4
Warning: resolving _listen by linking to _listen@8
Warning: resolving _bind by linking to _bind@12
Warning: resolving _recvfrom by linking to _recvfrom@24
%USERPROFILE%\AppData\Roaming\cabal\i386-windows-ghc-7.8.2\HTTP-4000.2.17/lib
HSHTTP-4000.2.17.a(TCP.o):fake:(.text+0x196f): undefined reference to `shutdownW
inSock'
%USERPROFILE%\AppData\Roaming\cabal\i386-windows-ghc-7.8.2\HTTP-4000.2.17/lib
HSHTTP-4000.2.17.a(TCP.o):fake:(.text+0x2024): undefined reference to `shutdownW
inSock'


...


%USERPROFILE%\AppData\Roaming\cabal\i386-windows-ghc-7.8.2\network-2.5.0.0/li
bHSnetwork-2.5.0.0.a(HsNet.o):HsNet.c:(.text+0x76): undefined reference to `geta
ddrinfo@16'
%USERPROFILE%\AppData\Roaming\cabal\i386-windows-ghc-7.8.2\network-2.5.0.0/li
bHSnetwork-2.5.0.0.a(HsNet.o):HsNet.c:(.text+0x8d): undefined reference to `free
addrinfo@4'
collect2: ld returned 1 exit status
Failed to install cabal-install-1.20.0.2
cabal: Error: some packages failed to install:
cabal-install-1.20.0.2 failed during the building phase. The exception was:
ExitFailure 1


一 度Windowsのコマンドプロンプトやmsys2_shell.batのシェルでインストールして失敗した場合、その後 mingwxx_shell.batのシェルで再度実施しても失敗するようです。下記フォルダにあるパッケージデータベースを削除して、 mingwxx_shell.batのシェルでcabal installを再実行してください。
  • %USERPROFILE%\AppData\Roaming\cabalの、GHC 7.8用のフォルダ(32-bit版の場合、i386-windows-ghc-7.8.2)
  • %USERPROFILE%\AppData\Roaming\ghcの、GHC 7.8用のフォルダ(32-bit版の場合、i386-mingw32-7.8.2)


ą
とりあえずじなそ,
2013/06/26 7:09
Comments