模块依赖性

假设我们通过添加一个新的接口函数扩展了某个模块，如同在 发布处理 中的例子一样，其中给 ch3 添加了一个函数 available/0 。

假设如果我们还要在模块 m1 中添加一个到该函数的调用，那么如果新版本的 m1 先被载入并且在新版本的 ch3 被载入之前调用了 ch3:available/0 ，那么就会发生一个运行时错误。

因此，在升级的情况下， ch3 必须在 m1 之前载入；在降级的情况下则要反过来。这样，我们说 m1 是依赖于ch3 的。在发布处理指令中，这是通过元素 DepMods 来表达的：

  1. {load_module, Module, DepMods}
  2. {update, Module, {advanced, Extra}, DepMods}

DepMods 是 Module 所依赖的模块的列表。

例如：在应用 myapp 中的 m1 模块当从“1”升级到“2”或从“2”降级到“1”时，是依赖于 ch3 的：

  1. myapp.appup:
  2.  
  3. {"2",
  4.  [{"1", [{load_module, m1, [ch3]}]}],
  5.  [{"1", [{load_module, m1, [ch3]}]}]
  6. }.
  7.  
  8. ch_app.appup:
  9.  
  10. {"2",
  11.  [{"1", [{load_module, ch3}]}],
  12.  [{"1", [{load_module, ch3}]}]
  13. }.

如果 m1 和 ch3 属于同一个应用， .appup 文件应如：

  1. {"2",
  2.  [{"1",
  3.    [{load_module, ch3},
  4.     {load_module, m1, [ch3]}]}],
  5.  [{"1",
  6.    [{load_module, ch3},
  7.     {load_module, m1, [ch3]}]}]
  8. }.

注意，当降级的时候，还是 m1 依赖于 ch3 。 systools 知道升级和降级之间的区别并生成正确的 relup ，其中当升级的时候 ch3 会在 m1 之前加载，而当降级的时候 m1 会在 ch3 之前加载。