62

エコシステムの初心者には、小規模から中規模の OCaml プロジェクトを構築および管理するための標準的に推奨される方法が不明です。, &c.の基本を理解しています。これらはocamlc、従来の UNIX C コンパイラを十分に反映しており、単純に見えます。しかし、個々のファイルの 1 回限りのコンパイルのレベルを超えて、コンパイルを単純かつクリーンに管理する最善の方法は不明です。問題は潜在的なツールを探すことではなく、標準的な OCaml プロジェクトを構造化および構築するための (コミュニティの経験によって検証された) 1 つまたはいくつかの正しい (十分な) 方法を見つけることです。

私のモデルの使用例は、純粋な OCaml または OCaml と C の依存関係の、ささやかな、しかし重要なプロジェクトです。そのようなプロジェクト:

  1. 多数のソースファイルが含まれています
  2. 多くの標準ライブラリへのリンク
  3. 1 つ以上のサードパーティ ライブラリへのリンク
  4. オプションで、サブプロジェクトとして C ライブラリと OCaml ラッパーを含めます (ただし、(3) のように、これを個別に管理してサードパーティ ライブラリとして含めることもできます)。

いくつかの代替ツールが際立っています。

  • カスタム Makefile は、ほとんどのオープン ソース OCaml パッケージで共通の標準のように見えますが、イライラするほど冗長で複雑に見えます。控えめな C/C++ プロジェクトよりもさらに複雑です。さらに悪いことに、多くの一見単純な OCaml ライブラリでさえ、autoconf/automake を上に重ねてさらに複雑にしています。
  • ocamlbuildは、最小限の構成でビルドを自動化するための最新の合理化されたメカニズムを提供しているように見えますが、初心者向けに十分に文書化されておらず、OCaml エコシステムの紹介資料で例として示されておらず、公開されているさまざまな OCaml プロジェクトのいずれでも目に見えて使用されていません。インスピレーションを求めて閲覧しました。
  • OASISは、Cabal のようなパッケージ マネージャーとライブラリの構築をサポートするために、他のビルド システムの上にある規約とライブラリ コードのレイヤーのようです。

(私はまた、OCaml を含む一般的な言語の標準ルール一式を含む自称 " " のように見えるOMakeと、GNU の標準ルールのテンプレートを提供するocaml-make (旧称 OCamlMakefile) を見てきました。)make++make

これらのいずれかが、OCaml ビルドを管理する好ましい最新の方法ですか?

プロジェクト ファイルはどのように構成するのが最適ですか?

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

4

5 に答える 5

23

利用可能なオプションの完全なリストがありますが、この質問には明確な答えがありません。私の個人的な推奨事項は、ocamlbuildを使用することでもあります。ここで提供されるmyocamlbuild.mlファイルは良いスタートです。これにより、さまざまなライブラリに依存するプロジェクトを簡単にコンパイルできます。Cライブラリへのバインドの場合を処理するとは思いませんが、wikiに役立つ可能性のある追加の例があります。

ocamlbuildはさらに別のビルドツールであり、パッケージマネージャーの仕事を複雑にするため、反対する人もいます。しかし、その使いやすさと公式ディストリビューションに含まれているという事実により、ますます広く使用されるようになっています。

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

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

于 2011-05-11T12:43:56.307 に答える
15

個人的には、ocamlbuild に +1 を付けます。デフォルトのルールは、小規模から中規模のプロジェクトを 1 つのコマンドでコンパイルし、非常に最小限の構成にするのに十分です。また、いくつかの非常に合理的な規則を適用します (ソースとビルド結果を混在させない)。また、大規模なプロジェクトでは、追加のルールとプラグインを使用して、希望に合わせてカスタマイズできます. 私が働いている会社では、大規模なプロジェクト(Ocaml + いくつかの C + いくつかの前処理 + ...) に使用しており、魅力的に機能します (そして、Makefile よりも頭痛の種がはるかに少なくなります)。

マニュアルについては、ユーザー ガイド (著者の Web ページから入手可能) で十分だと思います。よりファンキーなものには、もう少し掘り下げる必要があるかもしれません。

于 2011-05-10T21:45:01.563 に答える
10

OMakeの場合は+1。

数年前にビルド インフラストラクチャを刷新し、次の理由で OMake を選択しました。

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

正直なところ、ocamlbuild でそれを実行できたかどうかはわかりません。テストしていません。このツールは、OCaml のバグトラッカーでいくつかの活動が行われているため、確実に使用されています。ocamlbuild を選択する場合は、最新バージョンの OCaml があることを確認してください。

* OMake は、少し分かりにくい方法でソース外のビルドをサポートしています。ソースが読み取り専用の場合にも、いくつかの問題があります。Windows バージョンの OMake にパッチを適用して再構築する必要がありました。

于 2011-05-11T13:51:07.563 に答える
3

良い質問。私は言う傾向があります：

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

于 2012-05-22T17:57:58.040 に答える