いい質問ですね!私は他の答えを見ることに本当に興味がありますが、ここに私のプロジェクトを整理する方法があります:
まず第一に、私は Eclipse を優れたOCalIDEと共に使用します。これは非常にクールな Eclipse プラグインであり、積極的にメンテナンスされています。
あなたが Emacs ユーザーなら、TypeRexを使うことができます(これは死んでいますが、OCaml コミュニティの動きが非常に遅いため、時間はいくらでもあります)。あなたが Vim ユーザーなら、常に Omlet がありますが、本当に良い解決策はありません。
Eclipse では、「Managed Ocaml Project」を選択できます。つまり、基本的に、コンパイルについて心配したくないので、このプロジェクトを共有することはありません。
個人的なプロジェクトや一時的なテストには十分です。ただし、それができない場合は、「Ocaml Makefile プロジェクト」と「ocamlbuild を使用した Ocaml プロジェクト」のどちらかを選択する必要があります。Makefile を選択すると、はるかに柔軟で簡単なソリューションになります。
Eclipse は、コメントで非常によく説明されているOcaml プロジェクトのデフォルトの Makefile を提供します。Ocaml ビルド システムに慣れていない場合は、これを使用することをお勧めします。もしそうなら、デフォルトのものは大きすぎて読めないので、独自の Makefile を使用することをお勧めします (私はそう思います)。
すごい !これで、お気に入りのエディターにプロジェクトが作成され、グローバル構造を配置する準備が整いました。
プロジェクトのルートでは、古典的な GNU tarball の規則に従っています。
/
|- src/ # source files
|- lib/ # dependencies
|- test/ # tests files and test binaries
|- _build/ # binaries and object files, sometimes managed by ocamlbuild
|- AUTHORS # who did that marvelous stuff
|- README # what is it
|- Makefile # *always* provide a Makefile, you never know...
|- _tags # when I use ocamlbuild
|- _oasis # when I use oasis
lib ディレクトリがない場合もありますが、これは問題ありません。しかし、AUTHOR と README ファイルを提供する必要があります。なぜなら、それはあなたのプロジェクトにとって非常に有益だからです。
それは退屈な部分でした。src ディレクトリはどうですか?
- OCaml モジュラー システムは、独自のコンテナー内のものを作成するのに非常に役立ちます。私は自分の経験から次のように述べています。
- ファンクタ以外には内部モジュールを使用しません
- モジュール自体の一貫性を保っています (ある種の黄金律)。そのため、私のモジュール名は主にデータ型または内部状態を持つ特定のコンテナーに関連しています (ジャバリストがシングルトンと呼ぶもの)
- 私はしばしば、2 つまたは 3 つの明らかに固有のモジュールを作成します。エントリ ポイント、すべての一般的な型を含むモジュール、および一般的に使用されるすべての関数を含むモジュールです。循環依存を回避します。
src/
モジュールの構造が実際に見えない限り、ディレクトリ内のすべてをフラットに保ちます (解析、AI コンピューティング、ネットワークなど)。Cプロジェクトと同じ方法です。
OCaml は簡潔な言語なので、ファイルはほとんどありません。C プロジェクトに関しては、ディレクトリ アーキテクチャをできるだけフラットに保つようにしてください。ディレクトリはモジュール名や名前空間の一部ではないことに注意してください。したがって、これはプログラマの便宜のためだけです!
- mli の部分: プロジェクトの目標によって異なります。これは私の方法論です:
- 唯一の一般的なルールは、mli が存在する場合は文書化することです。Mlis は、コンパイラとプログラマを支援するためにここにいます。
- それはあなたのためですか?ml 部分にドキュメントを作成し、制約を入力するための mli のみを生成するか、大きすぎて閲覧できない ml を生成します。
- プロジェクトを配布しますか? 選択肢がある場合に最初に読み取るファイルであるため、mli に文書化します。インターフェースを生成するファイルを選択してください。中には内部ファイルもあり、カジュアルなユーザーに読まれたくないものもあります。
- OCaml オブジェクト システムを扱うときは、非常にすぐに乱雑になる可能性があるため、これらは常に必要です。
一般的なケースでは、mli をできるだけ少なくして、ゲストが知っておくとよいファイルと内部/高度なファイルをすぐに把握できるようにしています。
さらに、先に進むのを妨げるタイプの制約がないため、リファクタリングに役立ちます。
テスト スイートは、何も壊れていないことを確認するためにここにあることに注意してください ( OUnitを参照してください。ディストリビューションはパッケージ化されているはずです。非常にシンプルで効率的な、優れたプロジェクトです)。
それだけです。それが誰にも役立つことを願っています!