2013-06-26 7 views
5

私はいくつかの他のライブラリと、もちろん、haskellランタイムに依存するライブラリを持っています。 C APIをエクスポートします。 私はそれが完全に自己完結型であり、ユーザがhaskell、cabalおよびすべての依存関係のインストールに煩わされないように構築したいと考えています。カバール付き自己完結型ライブラリを構築するにはどうすればよいですか?

+0

ライブラリーユーザーがライブラリーとやり取りする方法を想像しますか? 1つのオプションはパッケージ(rpm、deb、dmgなど)を作成することですが、もう1つのオプションはライブラリのソース配布に数百万メガバイトのビルドインフラストラクチャを追加することです。 –

+0

@ ThomasM.DuBuisson私は彼がマルチプロジェクトのソリューションに類似したものを望んでいると思います。 –

+0

@ ThomasM.DuBuisson彼らはgccを使って自分のコードをライブラリとリンクします。これはghcが次のように呼び出すときと同じです: 'ghc -no-hs-main -static test.c libMylibrary.a ' – user1887615

答えて

1

それは完全に自己完結したユーザーは、あなたがそのすべての依存関係を使用して、ライブラリを配布する必要がありますインストールハスケル、秘密結社およびすべての依存関係

に煩わされないであろう - Haskellのコンパイラ、ランタイム、Cライブラリ、Cabal、依存ライブラリこれは自明な作業です。Haskell Platform.

HPソースを変更してインストーラを生成することができます。あなたのライブラリーのスタンドアロンインストーラーになります。

+0

私はそれほど理由が分かりません。すべての依存関係の.aファイルを明示的にリストすることによって、私のライブラリを呼び出すテストCファイルを構築できます。すべての依存関係を1つの大きな.aにまとめてライブラリとして配布することはできないでしょうか?私は、ライブラリをCコードから呼び出す必要があり、haskellコードから呼び出す必要はありません。 – user1887615

+0

はい、すべての依存関係を取り、それをリンクする独自のインストーラ/バンドラを書くことができます。 –

関連する問題