mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(tvix): update WASM status

Browse source 
crate2nix can now build WASM, and cl/11859 showcases this now.

Even if it's not in the same cargo workspace, we should still migrate
tvixbolt to a crate2nix build.

Remove the part about Build/Store frontends, it was more of an
explanation why we want WASM builds to be nice, it can be tracked in
separate TODOs once more concrete.

Change-Id: If4f5e0994b55520ba70cabefb4fcef9dc17bc394
Reviewed-on: https://cl.tvl.fyi/c/depot/+/11945
Tested-by: BuildkiteCI
Reviewed-by: Ilan Joselevich <personal@ilanjoselevich.com>
Reviewed-by: flokli <flokli@flokli.de>
Autosubmit: flokli <flokli@flokli.de>
This commit is contained in:
Florian Klink 2024-07-04 17:14:45 +03:00 committed by flokli
parent 6037888e18
commit af933c177a
1 changed files with 6 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
tvix/docs/src/TODO.md
View file

@ -30,26 +30,12 @@ Most of Tvix is living inside a `//tvix` cargo workspace, and we use `crate2nix`
as a build system, to get crate-level build granularity (and caching), keeping as a build system, to get crate-level build granularity (and caching), keeping
compile times somewhat manageable. compile times somewhat manageable.
In the future, for Store/Build, we want to build some more web frontends, Thanks to the recent crate2nix fixes, we can now use it to build WASM.
exposing some data by calling to the API. Being able to write this in Rust, We should migrate `//web/tvixbolt` from `rustPlatform.buildRustPackage` to
and reusing most of our existing code dealing with the data structures would `crate2nix`.
be preferred. An initial cl/11821 to move it to the `//tvix` workspace got some pushback, we
should see if it's possible to keep it in a separate directory and still refer
However, using the crate2nix tooling in combination with compiling for WASM is to the (cleaned) sources described in `tvix/default.nix`.
a bumpy ride (and `//web.tvixbolt` works around this by using
`rustPlatform.buildRustPackage` instead, which invokes cargo inside a FOD):
`buildRustCrate` in nixpkgs (which is used by `crate2nix` under the hood)
doesn't allow specifying another `--target` explicitly, but relies on the cross
machinery in nixpkgs exclusively.
`doc/languages-frameworks/rust.section.md` suggests it should be a matter of
re-instantiating nixpkgs for `wasm32-unknown-unknown`, but that's no recognized
as a valid architecture.
The suggested alternative, setting only `rustc.config` to it seems to get us
further, but the `Crate.nix` logic for detecting arch-conditional crates doesn't
seem to cover that case, and tries to build crates (`cpufeatures` for `sha{1,2}`)
which are supposed to be skipped.
## Perf ## Perf
- String Contexts currently do a lot of indirections (edef) - String Contexts currently do a lot of indirections (edef)