OCamlプロジェクトを構築および構築するための好ましい方法は何ですか？
エコシステムの初心者には、中小規模のOCamlプロジェクトの構築を構築および管理するための標準的に好ましい方法が何であるかは不明です。 ocamlc、＆c。の基本を理解しています。これらは、従来のUNIXCコンパイラを十分に反映しているため簡単に見えます。しかし、個々のファイルの1回限りのコンパイルのレベルを超えると、コンパイルを単純かつクリーンに管理するための最善の方法が明確ではありません。問題は潜在的なツールを探すことではなく、標準的なOCamlプロジェクトを構築および構築するための1つまたはいくつかの正しい（十分な）方法（コミュニティの経験によって検証されている）を見ることです。
私のモデルのユースケースは、純粋なOCamlまたはOCamlにCの依存関係を加えた、控えめですが重要なプロジェクトです。そのようなプロジェクト：
- 多数のソースファイルが含まれています
- 多数の標準ライブラリへのリンク
- 1つ以上のサードパーティライブラリへのリンク
- オプションで、サブプロジェクトとしてCライブラリとOCamlラッパーが含まれます（ただし、これは個別に管理して、（3）のようにサードパーティライブラリとして含めることもできます）
いくつかの代替ツールが際立っています。
- カスタムMakefileは、ほとんどのオープンソースOCamlパッケージで一般的な標準のようですが、イライラするほど冗長で複雑に見えます。控えめなC/C++プロジェクトよりもさらにそうです。さらに悪いことに、一見単純に見える多くのOCamlライブラリは、さらに複雑にするためにautoconf/automakeを上に重ねています。
- ocamlbuild は、最小限の構成でビルドを自動化するための最新の合理化されたメカニズムを提供しているようですが、初心者向けに十分に文書化されておらず、OCamlエコシステムの紹介資料に例として示されておらず、誰もが目に見える形で使用していません私がインスピレーションを得るために閲覧したさまざまな公開されたOCamlプロジェクトの。
- [〜＃〜] oasis [〜＃〜] は、Cabalなどのパッケージマネージャーとライブラリのビルドをサポートする他のビルドシステムの上にあるコンベンションとライブラリコードのレイヤーのようです。
（私も見ました OMake 、これは自称「make++ "には、OCamlを含む一般的な言語の一連の標準ルールも含まれています。 ocaml-make nee OCamlMakefileは、GNU makeの標準ルールのテンプレートを提供します。 。）
これらのいずれかがOCamlビルドを管理するための好ましい最新の方法ですか？
プロジェクトファイルはどのように最適に構成されていますか？
サードパーティのライブラリの依存関係はどのように含まれ、管理されていますか？それらをシステムレベルでインストールすることをお勧めしますか、それともプロジェクトに対してローカルでそれらを管理するための標準的で直接的な方法がありますか？私は、プロジェクトが可能な限り自己完結型のままであるモデルを大いに望んでいます。
利用可能なオプションの完全なリストがありますが、この質問には明確な答えがありません。私の個人的な推奨事項は、ocamlbuildを使用することでもあります。提供されているmyocamlbuild.mlファイル ここ は良いスタートです。これにより、さまざまなライブラリに依存するプロジェクトを簡単にコンパイルできます。 Cライブラリへのバインドの場合を処理するとは思いませんが、 wiki に役立つ可能性のある追加の例があります。
Ocamlbuildはさらに別のビルドツールであり、パッケージマネージャーの仕事を複雑にするため、反対する人もいます。しかし、その使いやすさと公式ディストリビューションに含まれているという事実により、ますます広く使用されています。
これをすべてスキップして、オアシスを直接使用することもできます。非常に新しく、安定版のリリースはまだ発表されていませんが、非常に使いやすいです。 myocamlbuild.mlが自動的に生成されます。まだではないにしても、これはおそらく非常に近い将来に進む方法です。さらに、オアシスを使用することで、開発中のOCaml用のCPANのようなシステムであるoasis-dbのメリットをすぐに得ることができます。
ライブラリの管理に関しては、答えはocamlfindです。 OCamlの複数のインスタンスがインストールされている場合、ocamlfindをすべてのライブラリに体系的に使用すると仮定すると、ocamlfindの適切なコピーを呼び出すと、ライブラリへのすべての参照がその特定のインスタンスの参照になります。私は現在、godiを使用してOCamlとライブラリをインストールしています。 ocamlfindを使用しており、OCamlの複数のインスタンスをインストールしても問題ありません。
個人的にはocamlbuildに+1を付けます。デフォルトのルールは、1つのコマンドで中小規模のプロジェクトをコンパイルするのに十分であり、構成はほとんどありません。また、いくつかの非常に合理的な規則を適用します（ソースとビルド結果を混在させないでください）。また、大規模なプロジェクトの場合は、追加のルールとプラグインを使用して、必要に応じてカスタマイズできます。私が働いている会社では、それを 大規模プロジェクト （Ocaml +いくつかのC +いくつかの前処理+ ...）に使用しており、魅力のように機能します（そして、Makefileよりもはるかに頭痛が少なくなります）。
マニュアルに関しては、ユーザーガイド（ 作者のウェブページ から入手可能）で十分だと思います。ファンキーなものを増やすには、もう少し掘り下げる必要があるかもしれません。
おまけは+1。
数年前にビルドインフラストラクチャを刷新し、次の理由でOMakeを選択しました。
- 当社の製品は、C、C++、Managed C++、Ruby、およびOCamlの混合物で構成されています。
- linuxとWindowsの両方を対象としています。
- ビルド時にデータベースとやり取りします。
- 一部のプロダクションでは、OCaml3.10を使用する必要がありました。
- オリジナルのビルドシステムはautoconf/automakeを使用していました。
- ソース外のビルド*が必要です。
正直なところ、ocamlbuildでそれができたかどうかはわかりませんが、テストはしていません。 OCamlのバグトラッカーでツールの周りにいくつかのアクティビティがあるので、ツールは確かに使用されています。 ocamlbuildを選択する場合は、OCamlの最新バージョンを使用していることを確認してください。
* OMakeは、少し非自明な方法でソース外ビルドをサポートします。ソースが読み取り専用の場合にもいくつかの問題があります。WindowsバージョンのOMakeにパッチを適用して再構築する必要がありました。
良い質問。私は言う傾向があります：
1）ocamlbuild効率的で高速であり、公式ディストリビューションによって提供されるデフォルトのツールであるため、コンパイルの標準的な方法である可能性があります。それが公式の配布にあるという事実は、それが時間とともに残る可能性が高いので、良い点です。さらに、ocamlfindが有効になっているため、パッケージをインストールするためのもう1つの標準であるocamlfindでインストールされたパッケージを管理できます（ocamlfindはCのpkg-configに少し似ています）
2）しかし、それはあなたのプロジェクトにとって十分ではありません。 Cとの統合は、ocamlbuildの基本です。したがって、ここでは、オアシスを使用して最終的に質問に答えることをお勧めします。おまけもやってみましたが、気に入らなかったです。
3）ただし、他の人が自分のマシンにプロジェクトをダウンロードしてビルドできるようにしたくない場合は、ビルドスクリプトが正しく機能しない可能性があります。さらに、oasisはpkg-configを処理しません。これらの理由から、ocaml-autoconf（autotoolsのocamlマクロ）を使用することをお勧めします。 autotoolsはCライブラリを管理するための標準であり、パッケージメンテナにはよく知られているからです。クロスコンパイルも処理できます...
=> ocaml-ocamlbuildを使用したautoconf