如何妥善处理依赖包的更新

[MasterBalll]

• 尝试用如下方式管理代码
  • 在自建包仓库中，A 被 B1 & B2 & B3 依赖，B1 & B2 & B3 又被 C 依赖，C 是顶层包。
  • 这些包都用 xmake 维护，这样一来就需要在构建脚本和包描述中均写上依赖包的版本。
  • 在尝试的初期，仅使用单一版本依赖（e.g. add_requires("A 0.1.0") & add_deps("A 0.1.0")）。
• 遇到的问题
  • 某天 A 更新了，Bn (n=1,2,3) 的构建脚本和包描述中的 A 的版本都需要更新，于是 Bn 的版本也更新了，那么 C 中 Bn 的版本也要更新。
  • 不仅如此，还需要安装全部这些 A,B,C 的新版本。
  • 让人头大，因为起因可能仅仅是 A 的一点点改动，而 B,C 的代码根本没变。
• 可能的办法
  • 一个是在包描述中生成 xmake.lua 在安装时使用，能够少改一处，但在需要改包的时候没有构建脚本可用了。
  • 另一个是不去写死版本，这样 A 更新了其他的都不用动，也只需要安装 A 的新版本，确实看起来不错，但在需要对全套代码进行严格的版本锁定时，这种更新又带来了不确定性。

所以想问问有没有妥善的处理方式。

[waruqi]

另一个是不去写死版本，这样 A 更新了其他的都不用动，也只需要安装 A 的新版本，确实看起来不错，但在需要对全套代码进行严格的版本锁定时，这种更新又带来了不确定性。

开启版本锁定，仅在需要更新时，执行 xmake require --upgrade

https://xmake.io/#/zh-cn/package/remote_package?id=%e4%be%9d%e8%b5%96%e5%8c%85%e7%9a%84%e9%94%81%e5%ae%9a%e5%92%8c%e5%8d%87%e7%ba%a7

[MasterBalll]

原来这个就能做到……尝试了一下，看来能初步解决问题。
关联讨论 #3388 (comment)
但如果像这样，除了 plat|arch，自定义 option 的不同值也会对应不同的级联依赖包配置，如何能针对这些自定义选项来记录不同的依赖包版本？（具体场景是在嵌入式开发中采用一个 option 来指定不同的嵌入式处理器核心，去对应特定核心的基础库）
另外，在构建脚本和包描述中同时进行包版本设置，这是常规用法吗？

[waruqi]

包里面配置 add_configs 参考包仓库其他包，然后 on_install 里对接内部 option

不同 configs 的 add_requires 是不冲突的

[MasterBalll]

嗯，option 对接包的 config 这一点没有问题。
问题是，比如我有一个叫 sim 的option ，在命令行配置成 xmake f xxx --sim=hifi2，这对应一套依赖包，配置成 xmake f xxx --sim=hifi3 ，这对应另一套依赖包，可是 xmake-requires.lock 似乎不会把这些不同的 sim 配置对应的依赖包都记录下来。