OCamlプロジェクトを構築して構築するための好ましい方法は何ですか？

Question

小規模から中規模のOCamlプロジェクトを構築および管理するための標準的な方法は、生態系の新入者にとっては不明です。私はocamlc、& cの基本を理解しています。彼らは従来のUNIX Cコンパイラをそのまま反映しています。しかし、個々のファイルの一回限りのコンパイルのレベルよりも、コンパイルを簡単かつきれいに管理するにはどうすればベストであるかは不明です。問題は潜在的なツールを探しているのではなく、標準OCamlプロジェクトを構築して構築するために、コミュニティの経験によって検証された1つまたは少数のRight（十分な）方法を見ています。

私のモデルのユースケースは、純粋なOCamlまたはOCamlにC依存関係を加えた、控えめながらも重要なプロジェクトです。このようなプロジェクト：

1. は、標準ライブラリの数に
2. リンク一つ以上のサードパーティのライブラリへ
3. リンク
4. ように任意にCライブラリとOCamlのラッパーを含むソースファイルの数が含まれていますサブプロジェクトいくつかの代替ツールが目立つ

（（3）のように、これはまた、個別に管理し、サードパーティのライブラリとして含めることもできるが）：

• カスタムメイクファイルは、ほとんどのオープンソースOCamlパッケージで共通の標準であるようですが、控えめに複雑で複雑なようです。控えめなC/C++プロジェクトよりもさらにそうです。さらに悪いことに、一見シンプルなOCamlライブラリでも、autoconf/automakeをレイヤーに重ね​​ることで、さらに複雑さを増すことができます。
• ocamlbuildは、最小限の設定でビルドを自動化するための最新の簡素化されたメカニズムを提供するように思われますが、新規ユーザーやOCamlエコシステムの入門資料ではあまりよく示されていません。インスピレーションのために閲覧したOCamlプロジェクト。
• OASISは、Cabalのようなパッケージマネージャとライブラリの構築をサポートするために、他のビルドシステムの上に規則とライブラリコードのレイヤーのようです。

（私も自称「make++」も標準ルールのテンプレートを提供し、OCamlで、かつocaml-make旧姓OCamlMakefileを含む一般的な言語の標準的なルールのスイートが含まれように表示される、OMakeを見てきましたGNU makeの場合）

これらのどれかが、OCamlビルドを管理するための最も現代的な方法ですか？

プロジェクトファイルはどのように構成されていますか？

サードパーティライブラリの依存関係はどのように含まれ、管理されていますか？システムレベルでインストールすることをお勧めしますか、プロジェクトにローカルで管理するための標準的かつ直接的な方法はありますか？私は、プロジェクトが可能な限り自己完結型であるモデルを好むでしょう。

Answer 1

利用可能なオプションの完全なリストがありますが、この質問には明確な答えはありません。私の個人的な推奨はocamlbuildを使うことです。 myocamlbuild.mlファイルはhereで提供されています。さまざまなライブラリに依存するプロジェクトを簡単にコンパイルできます。私はそれがCライブラリへのバインディングのケースを処理するとは思わないが、助けるかもしれないwikiの追加の例がある。

ocamlbuildがまだ別のビルドツールであるため、パッケージマネージャのジョブを複雑にするため、ocamlbuildに反対する人がいます。しかし、その使い易さとそれが公式の配布に含まれているという事実は、ますます広く使用されています。

これをすべてスキップして、オアシスを直接使用することもできます。非常に新しく、安定したリリースはまだ発表されていませんが、非常に使いやすいです。自動的にmyocamlbuild.mlが生成されます。これはおそらく非常に近い将来に行く方法です。さらに、オアシスを使用することで、開発中のOCaml用のCPANシステムのようなoasis-dbの利点がすぐに得られます。

ライブラリの管理に関して、答えはocamlfindです。 OCamlの複数のインスタンスがインストールされている場合、ocamlfindの適切なコピーを呼び出すと、自動的にすべてのライブラリに対してocamlfindを使用すると仮定すると、その特定のインスタンスのライブラリへの参照がすべて自動的に行われます。私は現在godiを使ってOCamlとライブラリをインストールしています。それはocamlfindを使用しており、OCamlの複数のインスタンスをインストールしても問題はありません。

Answer 2

個人的には、ocamlbuildに+1を付けます。デフォルトのルールは、1つのコマンドで中小規模のプロジェクトをコンパイルするのに十分であり、最小限の設定ではほとんどない。また、いくつかの非常に妥当な規則（ビルド結果とソースを混在させない）を強制します。大規模プロジェクトの場合は、特別なルールの&プラグインを使用して、自分の欲求に合わせてカスタマイズすることができます。私が働いている会社では、large project（Ocaml +いくつかのC +いくつかの前処理+ ...）のためにそれを使用しており、それは魅力的なように機能します（そして、Makefilesよりも頭痛を軽減します）。

マニュアルに関しては、私はユーザーガイド（author's webpageから入手可能）で始めるのに十分なはずだと思います。より多くのファンキーなものは、もう少し掘り起こす必要があるかもしれません。

Answer 3

+1 OMakeの場合。

は、我々は数年前に私たちのビルドインフラを刷新し、次のような理由でOMakeのを選択しました：

• 当社の製品は、C、C++、マネージドC++、RubyとOCamlでの混合物から構成されています。
• LinuxとWindowsの両方を対象としています。
• 私たちはビルド時にデータベースと対話します。
• いくつかのプロダクションでは、OCaml 3.10を使用する必要がありました。
• オリジナルビルドシステムはautoconf/automakeを使用しています。
• アウトソースビルド*が必要です。

私がocamlbuildで実行できたかどうかは分かりませんが、テストしていません。このツールは、OCamlのバグトラッカーでその周辺に何らかのアクティビティが存在するため、確実に使用されています。 ocamlbuildを選択する場合は、OCamlの最新バージョンがインストールされていることを確認してください。

* OMakeはアウト・オブ・ソースのビルドを少しでも明白にサポートしています。また、ソースが読み取り専用の場合にはいくつかの問題があります。 Windows版のOMakeをパッチして再構築する必要がありました。

Answer 4

良い質問私が言う傾向があるでしょう：

1）は、それが速く、効率的であり、公式の分布によって与えられたデフォルトのツールので、コンパイルするための標準的な方法である可能性が高い をocamlbuild。それが公式の配布にあるという事実は、時間とともに残る可能性が高いため、良い点です。さらに、ocamlfindが有効になっているので、ocamlfindでインストールされたパッケージを管理できます（ocamlfindはCのpkg-configと少し違います）。 Cとの統合はocamlbuildの基本です。だから、ここで私はあなたの質問に最終的に答えるためにオアシスを使うことをお勧めします。私もOMakeを試しましたが、好きではありませんでした。

3）ただし、他の人が自分のマシンでプロジェクトをダウンロードしてビルドすることができない場合、ビルドスクリプトはまったく機能しない可能性があります。さらに、oasisはpkg-configを処理しません。そのような理由から、ocaml-autoconf（autotools用のocamlマクロ）の使用をお勧めします。 autotoolsはCライブラリの管理の標準であり、パッケージ管理者にはよく知られています。また、ocamlbuildリンクが（今）壊れているocamlbuild