2011-05-10 95 views
56

生态系统新手尚不清楚建立和管理建筑中小型OCaml项目的正规首选方式。我理解ocamlc,& c的基础知识 - 它们反映了传统的UNIX C编译器,看起来很简单。但是,在单个文件的一次编译级别之上,不清楚如何最好地简单干净地管理编译。这个问题并不是在寻找潜在的工具,而是通过构建和建立标准的OCaml项目来看到一种或几种正确的(足够的)方法 - 正如社区的经验所证实的那样。构建和构建OCaml项目的首选方式是什么?

我的模型用例是一个适度但不重要的项目,纯OCaml或OCaml加上C依赖项。这样的项目:

  1. 包含了一些源文件
  2. 链接到一些标准库的
  3. 链接到一个或多个第三方库
  4. 任选地包括C库和OCaml的包装为的子项目(虽然这也可以单独管理,并将其作为一个第三方库,如(3))

若干备选工具中脱颖而出:

  • 自定义Makefiles似乎是大多数开源OCaml软件包中的通用标准,但看起来令人沮丧和复杂 - 甚至比适度的C/C++项目更加如此。更糟糕的是,许多看起来很简单的OCaml库在autoconf/automake层上面更加复杂。
  • ocamlbuild似乎提供了一个现代的,简化的机制,以最少的配置进行自动化构建,但对于新手来说并没有很好的文档记录,也没有在OCaml生态系统的介绍性材料中用实例代表,也没有被任何已发布的OCaml项目,我曾浏览过灵感。
  • OASIS似乎是其他构建系统顶层的约定和库代码层,以支持构建包管理器和库,如Cabal。

(I也看到OMake,这似乎是一个自封“make++”,这也包括一套共同语言,包括OCaml的标准规则,以及ocaml-make娘家姓OCamlMakefile,提供的标准规则的模板对于GNU make。)

这些是管理OCaml构建的首选的现代方式吗?

项目文件的结构如何?

如何包含和管理第三方库依赖项?是否希望在系统级别安装它们,或者是否存在以本地方式管理项目的标准和直接方式?我更喜欢一个模型,尽可能保持项目的独立性。

+0

的ocamlbuild链接(现在)打破了。 –

+0

链接现已修复 – ygrek

回答

21

你已经有了可用选项的完整列表,但是这个问题没有明确的答案。我个人的建议也是使用ocamlbuild。 myocamlbuild.ml文件提供的here是一个好的开始。它将允许您轻松编译依赖各种库的项目。我认为它不处理绑定到C库的情况,但在wiki上有其他示例可能有所帮助。

有些人反对ocamlbuild,因为它是另一个构建工具,使包管理器作业变得复杂。然而,它的易用性和包含在官方发行版中的事实正在使其越来越广泛地被使用。

你也可以跳过所有这些并直接使用绿洲。这是非常新的,稳定的版本尚未公布,但它非常实用。它会自动为你生成myocamlbuild.ml。如果不是这样的话,这很可能是不久的将来。此外,通过使用绿洲,您将立即获得oasis-db的好处,这是一个正在开发的OCaml CPAN系统。

关于管理库,答案是ocamlfind。如果您安装了多个OCaml实例,则调用ocamlfind的相应副本将自动使所有对库的引用都成为那些特定实例的引用,假设您对所有库都使用ocamlfind进行系统化。我目前使用godi来安装OCaml和库。它使用ocamlfind,并且我没有安装多个OCaml实例的问题。

+5

这个答案已经差不多三年了。我想分享我作为新人的经验。在经历了很多痛苦之后,我得出结论,通过ocamlfind来吞噬文档并使用ocamlc,ocamlopt和ocamlmklib是构建OCaml项目最痛苦的方式。我在这里记录了我的发现https://github.com/pacemkr/ocaml-scrypt/blob/master/Makefile我确定'oasis'是一个'myocamlbuild.ml'文件解决真正的问题。我尝试了,我确实有过,但是这两种工具在抽象其复杂性方面失败惨重。 –

+2

我认为我的回复也过时了。最近我一直在使用[OMake](http://omake.metaprl.org/),但我对所有的构建工具并不满意,希望最终会有一些基本上更好的东西出现。 –

+2

事情正在改善,“opam”并不关心构建系统,这很好。 'ocamlfind'使得使用'ocamlc'和朋友更容易。这两个让我足够接近。最难的部分是理解所有中间工件(cm *)以及它们来自哪里,以及'cclib'和类似标志的间接方式,它们如何与包一起传递,定制运行时构建等。 –

14

就我个人而言,我会给ocamlbuild +1。它的默认规则足够用一个命令编译小型到中型项目,而没有一个编译器的配置很少。它还执行一些非常合理的约定(不会混合源代码和构建结果)。而对于较大的项目,可以根据自己的愿望进行定制,使用额外的规则&插件。在我工作的公司,我们使用它作为large project(Ocaml +一些C +一些预处理+ ...),它的功能就像一个魅力(并且让我们比Makefiles更少麻烦)。

至于手册,我认为用户指南(可从author's webpage,)应该足以让你开始。更时髦的东西可能需要更多的挖掘。

+0

完全同意。我参与了一个使用ocamlfind,预处理和c的大型项目,但没有太多问题。 – nlucaroni

+1

在我的平行调查中,这似乎是最有吸引力的。一旦我开始跟踪它,我会报告回来。 – jrk

+7

对于所有ocamlbuild粉丝来说:记住*你*可以通过帮助编写文档,发布自己感兴趣的自制'myocamlbuild.ml'文件的片段,甚至可能对代码做出贡献来改进该工具(但为此你应该首先与开发者联系),以获得你想要的功能(我的愿望清单中的简单目标:允许调用ocamldoc来生成点图)。 – gasche

10

对于OMake +1。

我们几年前装修了的基础设施建设,并选择OMake,原因如下:

  • 我们的产品是由C,C++,托管C++,Ruby和OCaml中的混合物。
  • 我们既定位Linux又定位Windows。
  • 我们在构建时与数据库进行交互。我们不得不使用OCaml 3.10。
  • 我们的原始构建系统使用了autoconf/automake。
  • 我们需要源代码构建*。

说实话我不知道我们是否可以用ocamlbuild做到这一点,我还没有测试过。由于OCaml的bug追踪器中存在一些活动,因此该工具确实在使用。如果您选择ocamlbuild,请确保您有最新版本的OCaml。

* OMake支持乱源建立在一个位非显而易见的方式。当来源为只读时,它也有一些问题。我们必须修补和重建我们的Windows版本的OMake。

+3

我想看看omake和ocamlbuild之间的比较。我已经使用omake取得了很大的成功。当我尝试ocamlbuild时没有那么多运气,但那是几年前。 – aneccodeal

3

很好的问题。我倾向于这样说:

1)ocamlbuild 它很可能是编译的标准方法,因为它是高效的,快速的,并且是官方发布的默认工具。事实上,这是官方发布的事实,因为它更有可能随时间而停滞。此外,它已启用ocamlfind,因此它可以管理使用ocamlfind安装的软件包,这是安装软件包的另一个标准(ocamlfind有点像C的pkg-config)

2)但它不足以满足您的项目。与C的集成与ocamlbuild基本相同。所以在这里,我可能会建议你使用绿洲来最终回答你的问题。我也尝试过OMake,但不喜欢它。

3)但是,如果您不希望其他人能够在自己的机器上下载和构建项目,那么您的构建脚本不太可能正常工作。此外,绿洲不处理pkg-config。出于这些原因,我倾向于建议您使用ocaml-autoconf(ocaml宏用于autotools)。因为autotools是管理C库的标准,并且它被包维护者所熟知。它也可以处理交叉编译...

=>的OCaml的autoconf与ocamlbuild

相关问题