如果使用的cargo版本不一样是否也要进行相应的修改呢

[AuTsing]

因为deno每个版本使用的rust工具链版本可能不太一样，那这个cargo是否也要做相应的修改呢？
如果每更新一个版本就要更新一次这个工具链，这样做是否会比较麻烦，我在想是否有更好的方案

[secext2022]

cargo 具有一定的跨 rust 版本的兼容性. 当 rustc 升级时, cargo 不一定需要升级. 可以尝试使用旧版 cargo + 新版 rustc 进行编译, 一般可以正常编译.

也就是说, 不必每次 rustc 升级版本时, 就也升级 cargo. cargo 的升级频率可以比 rustc 慢一些, 比如每隔几个 rustc 版本, 升级一下 cargo.

[secext2022]

deno 的这种交叉编译需求, 是比较特殊的. 如果还用目前的方案的话, 有两个方向:

• (1) 修改 deno, 使得 deno 对交叉编译提供更好的支持.

• (2) 修改 cargo, 把这个功能合并到 cargo 上游.

但是这两个方向可能都难以推进.

---

维持现状的话, 就是需要定期升级 cargo, 这个维护成本并不是很高, 大约一个人在一天之内可以完成, 如果不出意外的话.

[AuTsing]

我个人之前的操作就是把 build.rs 拿出来单独编译成目标架构然后上传到目标设备执行得到快照
后面我看到了你说还有 termux 的镜像我才联想到可以摆脱目标设备
这就是我个人感觉最省事的办法了

确实，要在目标设备运行得到快照是一个比较棘手的问题
但对于编译 deno 来说，只有快照这一步需要在目标平台运行
所以为了这一步需要维护一个自定义的 cargo 任务是不是似乎有点过于过大了

我个人是更倾向于维护一个快照 builder 仓库，目标是只要得到快照就行
然后在编译 deno 时只需要替换掉原来的快照，这样应该对于编译 deno 来说入侵程度应该时最小的吧

[AuTsing]

deno 的这种交叉编译需求, 是比较特殊的. 如果还用目前的方案的话, 有两个方向:

• (1) 修改 deno, 使得 deno 对交叉编译提供更好的支持.
• (2) 修改 cargo, 把这个功能合并到 cargo 上游.

但是这两个方向可能都难以推进.

维持现状的话, 就是需要定期升级 cargo, 这个维护成本并不是很高, 大约一个人在一天之内可以完成, 如果不出意外的话.

我觉得第一项应该彼第二项容易实现得多，毕竟 编译脚本 要在不同架构的设备上面运行这个似乎是非常罕见的，似乎没有足够的理由添加这么一个功能

[secext2022]

"把 build.rs 单独拿出来" 如果不修改 cargo 的话, 就需要对 deno 的代码进行 大量 的修改, 比较麻烦.

并且 deno 发布新版本比较频繁, 维护一个关于 deno 的仓库维护工作量较大.

而 cargo 的升级频率比 deno 低很多, 并且对 cargo 的修改比较简单, 所以维护 cargo 的工作量相对较小.

[secext2022]

deno 官方的代码并不支持 Android, 为了编译 Android 版本, 需要对 deno 的代码进行一定的修改, 并禁用一些功能 (比如 deno_ffi, webgpu 等).

并且, deno 官方对于支持 Android 平台似乎兴趣不大.

[secext2022]

另外, 最新版 deno 能够成功在 Android 运行嘛 ?

我之前编译了新版 deno 的 aarch64 Android 版本, 结果无法运行, 关于 v8 的部分直接崩溃了.

[AuTsing]

据我观察应该没有很大量的修改

https://github.com/AuTsing/deno_snapshot_builder_qemu
https://github.com/AuTsing/cmdroid_deno

以上这两个仓库是我成功编译的
没有修改很多地方，只是在 deno cli 的 build.rs 的最后一步添加了一个替换步骤

我知道在旧版本(我之前用的v1.31)有相当多地方无法通过编译的地方，因为没有添加对安卓的支持
可是在新版(v1.39)好像官方已经merge了你的补丁，所以在编译的时候并没有遇到很多障碍

至于需要禁用的一些功能 (deno_ffi, webgpu) 因为我个人没有用到这些个功能，所以没有测试过是否可用
如果禁用以上功能是必要步骤的话，对于 修改自定义 cargo 来说不也是要做的步骤嘛
(其实不禁用是不是也可以，不管他的话，可以尽可能少修改源码)

[AuTsing]

我目前正在使用的版本是 v1.39.4，最新版的暂时没有去测试，后续如果有时间我会再尝试编译更新的版本

[secext2022]

我之前编译 deno 1.41 版本的, 失败了, 无法运行 (v8 直接崩溃)

上面说的移除 deno 的功能, 并不是因为使用, 而是如果不移除, deno 代码就无法在 Android 编译.

[AuTsing]

最新版的 v8 中重新添加了 Android 的编译产物
这是通过CI的了吧，应该不会有问题吧

[secext2022]

最新版 deno_core 仍然在 Android 上崩溃.

denoland/deno_core#738

[secext2022]

最新版的 v8 中重新添加了 Android 的编译产物 这是通过CI的了吧，应该不会有问题吧

最新发现: 导致 deno_core 崩溃的部分对应的测试, 在 rusty_v8 的 CI 测试中被跳过了