如何使用Oasis (或不带Oasis)构建多级模块层次结构

Question

假设我有一组模块，每个模块都是带有子模块的"bushy“。

M1.X        M2.X        M3.X
M1.Y        M2.Y        M3.Y
M1.Z        M2.Z        M3.Z
M1.W        M2.W        M3.W
M1.Q        M2.Q        M3.Q
M1.P        M2.P        M3.P

此外，我希望这些灌木丛中的每一个坐在一个主模块下。

Home.M1
Home.M2
Home.M3

现在，可以很容易地使用Oasis的M1、M2和M3选项来构造项目目录。特别是，我喜欢并试图解决的问题是：(a)以标准.ml/.mli格式编排文件的能力；(b)让ocamldoc生成正确链接的文档。

但是，由于我希望在一个公共模块层次结构下在同一个库中分发每个M1、M2和M3，所以我不能使用Pack:，而是被迫将整个该死的东西扔到一个文件中，以便(a)不意外地破坏全局命名空间，(b)不会意外地在不打算直接使用的Home.命名空间中扩散模块，以及(c)不会破坏ocamldoc链接。

因此，我的问题是，在符合上述目标的前提下，如何使用Oasis创建包含此表单的分层模块的包？

其他一些制约因素包括：

• M1.、M2.和M3.命名空间下的模块之间的冲突不是偶然的--这也发生在真正的情况下！
• M2.和M3.命名空间中的模块依赖于M1.命名空间中的模块。

我的偏好是能够找到一个也允许合理的文件布局的解决方案。

src -+
     +-- m1 -+
     |       +-- x.ml
     |       +-- x.mli
     |       +-- y.ml
     |       +-- y.mli
     |       +-- z.ml
     |       +-- z.mli
     |       |
     |       ...
     |
     |
     +-- m2 -+
     |       +-- x.ml
     |       +-- x.mli
     |       +-- y.ml
     |       +-- y.mli
     |       +-- z.ml
     |       +-- z.mli
     |       |
     |       ...
     |
     |
     +-- m3 -+
             +-- x.ml
             +-- x.mli
             +-- y.ml
             +-- y.mli
             +-- z.ml
             +-- z.mli
             |
             ...

对绿洲来说，这也可能是不可能的。在这种情况下，关于如何使用其他构建工具的建议是可以接受和欢迎的。假设我对其他工具知之甚少。因为这可能是真的！

Answer 1

与绿洲

pack in oasis有一点损坏，因为它将所有路径都包含到搜索路径中，从而破坏了命名空间。有一个长期存在的被接受的错误请求，但事情仍然在他们的地方。但是，如果它工作正常，它可以帮助您，因为它将创建一个库名称空间，允许您在不同的文件夹中拥有同名的模块。但是，它不起作用，所以我们应该忘记它。

我们在巴普项目中所采取的方法是用丑陋的bap_subproject_前缀破坏所有模块的名称，以保护我们免受与自己模块的冲突，以及来自外部库的冲突。对于每个bap_subproject，我们都有一个文件夹，其中有所有的实现模块，名字都是乱七八糟的，还有一个伞式模块来管理它们。该模块存储在文件bap_subproject.ml中，其中定义了要导出的所有模块和类型的别名。通常它包含的条目如下：

module X = Bap_subproject_x

还有一个大型的Bap项目，它将所有的子库合并到一个名称空间Bap.Std下，并重新导出它所需的一切，以便在拥有一个open Bap.Std之后，访问在bap_disasm/bap_disasm_insn.ml[i]中定义的Insn模块。

无绿洲

免责声明:如果您用插件扩展该解决方案，它可能仍然适用于oasis。

我们在一个项目中使用了这种方法，这是一个不幸的封闭源代码，所以我不能提供一个链接。每个子项目都生活在自己的子文件夹中，在它自己的命名空间中(我们在每个子文件夹中都有parser模块，没有任何坏消息)。对于每个子项目，在mlpack文件夹中都有一个top文件：

 root +
      |
      +-- expr.mlpack
      +-- expr -+
                |
                +- lexer.*
                +- parser.*
                +- ast.*
                +- ...
      +-- cameo.mlpack
      +-- cameo-+
                |
                +- lexer.*
                +- parser.*
                +- ast.*
                +- ...

expr.mlpack的内容如下：

   expr/Lexer
   expr/Parser
   expr/Ast
   ...

ocamlbuild将此expr.mlpack视为一个独立模块，其中定义了Lexer、Parser等子模块(并可作为Expr.Lexer访问)。而且，与同样具有Lexer的同级项目没有冲突，也没有与ocaml-libs或任何其他外部Lexer的冲突，因为expr文件夹实际上从未包含在搜索路径中。

如果您需要为您的系统添加另一个层，比如包包，那么您有三个选择：

1. 递归地使用相同的方法，即创建另一个超级文件夹，其中包含指向子文件夹的mlpack或mllib文件。
2. 只需添加引用所有mlpack'ed模块的mlpack
3. 创建重新引入所有模块的big.ml。

最后两种方法要求顶级打包模块当然有不同的名称。但通常情况下这是公平的。