• 模块依赖性

    模块依赖性

    假设我们通过添加一个新的接口函数扩展了某个模块，如同在 发布处理 中的例子一样，其中给 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 之前加载。