You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my ongoing efforts to be able to cross-compile Deno (to support the Conda packages on linux-aarch64, probably also useful for other downstream packaging scenarios as well), and the solution had working is now broken with a Rust upgrade, I think I have a solid potential solution, but would like to propose it here before trying to code on it.
Background: the core problem with cross-compiling Deno is that V8 snapshots are platform-dependent, and Deno does not support compiling and shipping binaries without snapshots (HMR is supported for development, but I haven't found a supported way to make a distributable binary without snapshots). I had cross-building working through the cargo-cross-build Cargo patches (and the Conda Deno linux-aarch64 build first built a patched Cargo, then used it to build Deno). This patch works by compiling designated crates' build scripts for the target environment instead of the build environment, and running them through an emulator.
The reason the patched Cargo was needed is that the snapshotting is built directly into the build.rs process, which is fully managed by Cargo.
Cross-building is necessary for Conda because the native AARCH64 builders are unreliable (a long-standing known problem), and the Deno build currently exhausts builder resources. I have experimented with repackaging the official Deno binaries, which is not the preferred Conda solution but is used by some packages with difficult build processes, but they rely on a newer version of glibc than is present in the Conda base and thus the packaging-time tests fail.
Proposed Solution: it should be possible to cleanly support cross-compiling Deno by separating the snapshotting logic into a separate snapshot directory / deno-snapshot workspace crate. This crate will be buildable as both a library and a binary. cli/build.rs will be modified to use the snapshot crate in library mode to replicate current behavior; it will also look for an environment variable (maybe DENO_SNAPSHOT_DIR?), and if found, it will use the snapshots from there instead of building new ones.
Normal builds can proceed unmodified. Cross-builds (for environments with working emulators) can proceed as follows:
Build snapshot binary for the target architecture.
Run snapshot binary through an emulator to obtain snapshots.
Build cli with the environment variable pointing to the pre-built snapshots.
This doesn't solve the problem for cross-building without a working emulator (e.g. building for OSX ARM64 from an OSX x86_64 builder), but will enable common cross-build scenarios (including for Linux distributions or embedded Linux scenarios if they need it).
(It would also be nice to be able to build working Deno binaries with snapshotting fully disabled, but that would be a separate feature request and/or PR I think.)
Thoughts?
The text was updated successfully, but these errors were encountered:
In my ongoing efforts to be able to cross-compile Deno (to support the Conda packages on linux-aarch64, probably also useful for other downstream packaging scenarios as well), and the solution had working is now broken with a Rust upgrade, I think I have a solid potential solution, but would like to propose it here before trying to code on it.
Background: the core problem with cross-compiling Deno is that V8 snapshots are platform-dependent, and Deno does not support compiling and shipping binaries without snapshots (HMR is supported for development, but I haven't found a supported way to make a distributable binary without snapshots). I had cross-building working through the
cargo-cross-build
Cargo patches (and the Conda Deno linux-aarch64 build first built a patched Cargo, then used it to build Deno). This patch works by compiling designated crates' build scripts for the target environment instead of the build environment, and running them through an emulator.The reason the patched Cargo was needed is that the snapshotting is built directly into the
build.rs
process, which is fully managed by Cargo.Cross-building is necessary for Conda because the native AARCH64 builders are unreliable (a long-standing known problem), and the Deno build currently exhausts builder resources. I have experimented with repackaging the official Deno binaries, which is not the preferred Conda solution but is used by some packages with difficult build processes, but they rely on a newer version of glibc than is present in the Conda base and thus the packaging-time tests fail.
Proposed Solution: it should be possible to cleanly support cross-compiling Deno by separating the snapshotting logic into a separate
snapshot
directory /deno-snapshot
workspace crate. This crate will be buildable as both a library and a binary.cli/build.rs
will be modified to use thesnapshot
crate in library mode to replicate current behavior; it will also look for an environment variable (maybeDENO_SNAPSHOT_DIR
?), and if found, it will use the snapshots from there instead of building new ones.Normal builds can proceed unmodified. Cross-builds (for environments with working emulators) can proceed as follows:
snapshot
binary for the target architecture.snapshot
binary through an emulator to obtain snapshots.cli
with the environment variable pointing to the pre-built snapshots.This doesn't solve the problem for cross-building without a working emulator (e.g. building for OSX ARM64 from an OSX x86_64 builder), but will enable common cross-build scenarios (including for Linux distributions or embedded Linux scenarios if they need it).
(It would also be nice to be able to build working Deno binaries with snapshotting fully disabled, but that would be a separate feature request and/or PR I think.)
Thoughts?
The text was updated successfully, but these errors were encountered: