Question

我知道这个问题非常笼统，我甚至不知道如何更好地提问。

我在C没有太多经验，我只是希望我能在OCaml和Java中做类似的事情。

例如，在Java中，我通常创建一个项目（使用Eclipse或其他IDE），然后我有一个src文件夹和一个bin文件夹。所有compiled内容都转到bin。

所以对于首发，我怎么能做一些像上面这么简单的事情？只是拆分源文件并轻松编译文件？

通常，你们如何组织OCaml项目文件？

最后一个问题是，我应该使用mli还是module？我注意到ocaml-batteries-included正在使用mli。

Answer 1

在OCaml社区中对这个主题有很多不同的看法，这实际上取决于你想要的结构或灵活性。我自己使用makefile和ocamlbuild，如果我是懒惰的，oasis用于其他一切。您应该查看一些随机的OCaml项目，看看它是如何工作的以及您想要的。例如，绿洲项目可能如此：https://github.com/avsm/ocaml-github。您只需要查看_oasis文件（如果您曾经使用过maven，请将其视为pom.xml）。运行oasis setup应该为您生成所有构建文件。 ocaml setup.ml -all后跟ocaml setup.ml -install将在您的系统上安装库。

至于使用mli的。对他们来说有一点点争议。以下是邮件列表中的讨论：http://www.mentby.com/Group/caml-list/why-should-i-use-mli-files.html

我自己的观点是，除非您的模块是其他人将使用的公共API的一部分，否则它们是可选的。在这种情况下，它们是强制性的

Answer 2

好问题！我真的很想看到其他答案，但这是我如何组织我的项目：

首先，我使用Eclipse与优秀的OCalIDE，这是一个非常酷的eclipse插件，积极维护。
如果您是Emacs用户，可以使用TypeRex（已经死了，但由于OCaml社区移动得非常慢，您将拥有所有时间）。如果你是Vim用户，总有Omlet，但没有任何非常好的解决方案。

使用Eclipse，您可以选择“Managed Ocaml Project”，这意味着基本上我不想担心编译内容，我永远不会分享这个项目。
从那开始，这对个人项目和临时测试来说已经足够了。但是，如果你不能，你将不得不在“Ocaml Makefile Project”和“Ocaml project with ocamlbuild”之间做出选择。选择Makefile，它更灵活，更容易解决。

Eclipse将为您提供a default Makefile for Ocaml projects，在评论中对此进行了很好的解释。如果您不熟悉Ocaml构建系统，我建议您使用它。如果你是，我建议你使用自己的Makefile，因为默认的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模块化系统非常有助于在自己的容器中制作东西。我根据自己的经验说明：
- 除了仿函数之外，我不使用内部模块
- 我让自己的模块保持一致（有点黄金法则）。为此，我的模块名称主要与数据类型或具有内部状态的特定容器相关（javaists称之为Singletons）
- 我经常制作两个或三个明显特定的模块：入口点，包含所有常见类型的模块，以及包含所有常用功能的模块。它避免了循环依赖。
我将所有内容保持在src/目录中，除非我能真正看到模块中的结构（那些是解析，那些是AI计算，那些是网络......）。就像我对C项目一样。

OCaml是一种简洁的语言，所以你应该有几个文件。对于C项目，尽量保持目录体系结构尽可能平坦，请记住该目录不是模块名称或命名空间的一部分，因此只有程序员方便！
mli部分：它实际上取决于您项目的目标。这是我的方法：
- 唯一的一般规则是：记录mli是否存在。 Mlis在这里帮助编译器和程序员。
- 是给你的吗？在ml部分中记录并仅生成mli用于键入约束或者太大而不能浏览ml。
- 您想分发您的项目吗？在mli中记录，因为如果我们有选择，我们将读取第一个文件。选择你将生成接口的文件，也许有些是内部的，你不希望他们被临时用户阅读。
- 当你处理OCaml对象系统时总是需要它们，因为它会很快变得混乱。

在一般情况下，我很高兴尽可能少地保留我的mli，以便客人立即知道哪些文件是有用的，哪些是内部/高级。

此外，它有助于重构，因为我没有类型约束阻止我继续前进请记住，测试套件是为了确保我们不会破坏任何东西（请参阅OUnit，您的发行版应该为您打包。这非常简单有效，项目很好。）

这就是我所看到的。希望能帮助任何人！

我该如何组织我的OCaml项目？

2 个答案: