59

.cabal ファイルは次のとおりです。

Name:                myprogram
Version:             0.1
-- blah blah blah
Cabal-version:       >=1.9.2

Executable myprogram
  HS-source-dirs:       src
  Main-is:              Main.hs
  Build-depends:        attoparsec == 0.10.*,
                        base == 4.3.*,
                        -- long long list of packages

Test-Suite test
  HS-source-dirs:       test, src
  Type:                 exitcode-stdio-1.0
  Main-is:              Main.hs
  Build-depends:        attoparsec == 0.10.*,
                        base == 4.3.*,
                        -- long long list of packages
                        QuickCheck == 2.4.*

テスト スイートのビルド依存パッケージの長いリストを「実行可能ファイルと同じものに QuickCheck を加えたもの」に置き換える方法はありますか?

編集：バージョン情報。

  • cabal-dev 0.9
  • cabal-install 0.10.2
  • カバル ライブラリ 1.10.2.0
  • GHC 7.0.4
  • Haskell プラットフォーム 2011.4.0.0
4

5 に答える 5

33

テスト スイートのビルド依存パッケージの長いリストを「実行可能ファイルと同じものに QuickCheck を加えたもの」に置き換える方法はありますか?

私が知っていることではありません。build-dependsただし、プロジェクトを 3 つのターゲットに構造化することで、パッケージのリストを一度だけ言及する方法があります。

  1. すべてのコードを含み、長いビルド依存リストを必要とするライブラリ。
  2. 1つのファイルのみで構成され、上記のベースとライブラリに依存する実行可能ファイル。
  3. 上記のライブラリと使用しているテスト パッケージに依存するテスト スイート。

おそらく、このアプローチは indygemma の回答が提案するものですが、Norman Ramsey がコメントで指摘しているように、そこで提案された Cabal ファイルはそれを完全には達成しません。Cabal ファイルに必要なものの主なポイントは次のとおりです。私にとって有効な完全な例については、この Cabal ファイルを参照してください。

name: my-program
version: ...

library
  hs-source-dirs: src-lib
  build-depends: base, containers, ...
  exposed-modules: My.Program.Main, ...

executable my-program
  hs-source-dirs: src-exec
  main-is: my-program.hs
  Build-depends: base, my-program

test-suite tests
  type: exitcode-stdio-1.0
  hs-source-dirs: src-test
  main-is: tests.hs
  other-modules: ...
  build-depends: base, my-program, test-framework, ...

重要なポイント:

  • 3 つのターゲットに対して 3 つの別個のソース ディレクトリがあります。これは、GHC が他のターゲットをビルドするときにライブラリ ファイルを再コンパイルするのを防ぐために必要です。

  • すべてのアプリケーション コードはライブラリにあります。実行可能ファイルは、次のような単なるラッパーです。

    import My.Program.Main (realMain)
main = realMain

  • ライブラリは、テストに必要なすべてのモジュールを公開します。

最後の点は、このアプローチの欠点を浮き彫りにしています。つまり、内部モジュールを公開する必要があります。このアプローチの主な利点は、Cabal ファイルの重複が少ないことです。さらに重要なのは、ビルド プロセスの重複が少ないことです。ライブラリ コードは 1 回だけビルドされ、実行可能ファイルとテスト スイートの両方にリンクされます。 .

于 2013-08-19T09:19:01.263 に答える
4

手動で .cabal ファイルを作成する代わりに、hpackを使用することも検討できます。

hpack の package.yaml 形式では、.cabal ファイルの生成時dependenciesにすべてのコンポーネントのフィールドにエントリが追加される共通フィールドを指定できます。build-depends

たとえば、hpack 独自のpackage.yamlと生成されたhpack.cabalを参照してください。

既存のパッケージで hpack の使用を開始するには、既存の .cabal ファイルから package.yaml を生成するhpack-convertを使用できます。

hpack を使用する新しいパッケージを作成するには、次のsimple-hpackようにスタックのテンプレートを使用できますstack new mypkg simple-hpack。

開発にスタックを使用する場合hpack、更新された package.yaml から .cabal ファイルを再生成するために手動で呼び出す必要はありません – スタックはそれを自動的に行います。

于 2016-10-08T23:02:21.710 に答える
-5

問題を解決する .cabal ファイル用のオプションのライブラリセクションがあります。

name:              myprogram
version:           0.1
-- blah blah blah
cabal-version:     >=1.9.2

library
    build-depends: attoparsec == 0.10.*
                 , base == 4.3.*
                 -- long long list of packages

executable myprogram
    hs-source-dirs: src
    main-is:        Main.hs

test-suite test
    hs-source-dirs: test, src
    type:           exitcode-stdio-1.0
    main-is:        Main.hs
    build-depends:  QuickCheck == 2.4.*
于 2012-04-15T16:58:52.887 に答える