首页 文章

构建和构建OCaml项目的首选方法是什么?

提问于
浏览
56

对于生态系统的新手来说,目前尚不清楚构建和管理中小型OCaml项目的规范首选方式 . 我理解 ocamlc 的基础知识,它们反映了传统的UNIX C编译器,看起来很简单 . 但是,高于单个文件的一次性编译水平,目前还不清楚如何简单干净地管理编译 . 问题不是寻找潜在的工具,而是通过社区的经验验证一种或几种正确(足够)的方法来构建和构建标准的OCaml项目 .

我的模型用例是一个适度但非平凡的项目,纯OCaml或OCaml加上C依赖项 . 这样一个项目:

  • 包含许多源文件

  • 链接到许多标准库

  • 指向一个或多个第三方库的链接

  • 可选地包括C库和OCaml包装器作为子项目(尽管这也可以单独管理并作为第三方库包含,如(3)中所示)

几个替代工具脱颖而出:

  • 自定义Makefile似乎是大多数开源OCaml包中的通用标准,但看起来令人沮丧的冗长和复杂 - 甚至比适度的C / C项目更令人沮丧 . 更糟糕的是,许多甚至看似简单的OCaml库层都将autoconf / automake置于顶层,以实现更高的复杂性 .

  • ocamlbuild似乎提供了一种现代化,简化的机制,可以使用最少的配置自动化构建,但是对于新手来说没有很好的文档记录,在OCaml生态系统的介绍性材料中也没有示例,也没有被各种已发布的OCaml项目明显使用我浏览过的是灵感 .

  • OASIS似乎是其他构建系统顶层的约定和库代码层,以支持构建包管理器和库,如Cabal .

(我也看过OMake,它似乎是一个自封的“ make++ ”,其中还包括一套常用语言标准规则,包括OCaml和ocaml-makenéeOCamlMakefile,为GNU make 提供标准规则模板 . )

这些中的任何一种都是管理OCaml构建的首选现代方式吗?

项目文件的结构如何最佳?

如何包含和管理第三方库依赖项?是首选在系统级别安装它们,还是有一种标准和直接的方式在项目本地管理它们?我更喜欢一种模式,其中项目尽可能保持独立 .

4 回答

  • 10

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

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

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

    关于管理图书馆,答案是ocamlfind . 如果安装了多个OCaml实例,则调用ocamlfind的相应副本将自动导致对库的所有引用都是针对该特定实例的引用,假设您对所有库系统地使用了ocamlfind . 我目前使用godi来安装OCaml和库 . 它使用ocamlfind,我可以安装多个OCaml实例 .

  • 3

    就个人而言,'d give +1 for ocamlbuild. It'的默认规则足以用一个命令编译中小型项目,没有编译到非常小的配置 . 它还强制执行一些非常合理的约定(不将源与构建结果混合) . 对于大型项目,它可以根据自己的需求进行定制,并提供额外的规则和插件 . 在我工作的公司,我们将它用于large project(Ocaml某些C进行一些预处理...),它就像一个魅力(并且让我们比Makefiles更少头痛) .

    至于手册,我认为用户指南(可从author's webpage获取)应足以让您入门 . 更时髦的东西可能需要更多的挖掘 .

  • 21

    OMake 1 .

    几年前我们改进了构建基础架构并选择了OMake,原因如下:

    • 我们的产品由C,C,Managed C,Ruby和OCaml的 .

    • 我们的目标是Linux和Windows .

    • 我们在构建时与数据库进行交互 .

    • 对于某些作品我们不得不使用OCaml 3.10 .

    • 我们的原始构建系统使用了autoconf / automake .

    • 我们需要out-of-source build * .

    说实话,我不知道我们是否可以用ocamlbuild完成它,我还没有测试过 . 该工具正在使用中,因为OCaml的bugtracker中存在一些活动 . 如果您选择ocamlbuild,请确保您拥有最新版本的OCaml .

    • OMake以一种非显而易见的方式支持源外构建 . 当源是只读时,它也有一些问题 . 我们必须修补并重建我们的Windows版本的OMake .
  • 14

    好问题 . 我倾向于说:

    1)ocamlbuild它可能是标准的编译方式,因为它是高效,快速的,并且是官方发行版提供的默认工具 . 它在官方发行中的事实是好的一点,因为它更有可能随着时间的推移而存在 . 此外,它启用了ocamlfind,因此它可以管理使用ocamlfind安装的软件包,这是安装软件包的另一个标准(ocamlfind有点像pkg-config for C)

    2)但对你的项目来说还不够 . 与C的集成是ocamlbuild的基础 . 所以在这里我可能会建议你使用绿洲来最终回答你的问题 . 我也试过OMake,但不喜欢它 .

    3)但是,如果您不希望其他人能够在自己的计算机上下载和构建项目,那么您的构建脚本不可能直接运行 . 此外,oasis不处理pkg-config . 出于这些原因,我倾向于建议您使用ocaml-autoconf(ocaml宏用于autotools) . 因为autotools是管理C库的标准,所以它是包维护者所熟知的 . 它还可以处理交叉编译......

    => ocaml-autoconf与ocamlbuild

相关问题