Wow, this is super interesting. I'm not aware of any platform that has attempted this, but I'm willing to give it a shot. To be clear, I'm expecting that you and other wonderful people like you are going to be supporting most of the Emscripten issues, but I'm happy to help you get things integrated properly. Let's compile the world. :)

A BinaryBuilder issue I ran into is that the sources for different components of Emscripten have the same base name (1.38.20.tar.gz).

This is unfortunate; I have half-converted things to prepend hashes before downloaded filenames (so, e.g. it should download it as <sha256>-1.38.20.tar.gz but there may be some code paths I missed. Give me a reproducer and I'll fix it.

My main goal is to try to support WebAssembly compilation of Julia code. This especially includes LLVM and some BLAS.

You want to compile .jl files to emscripten? How does this work help with that? I would think that something like FluxJS.jl would be more up your alley.

One is that emcc has to be run once in the builder to initialize it. Emscripten needs to write set up information in ~/.emscripten. I don't know how to pre-populate that, and I don't see a way to tell emcc to look somewhere else for this.

I wrote up instructions for how to hack this in, then wrote "ideally this should be set through an environment variable instead", then thought to myself "why don't I google around a bit and see if that's how this already works" and lo and behold: you should set EM_CONFIG to the path of your .emscripten file.

I do want to compile .jl files to WebAssembly using Emscripten. This work helps by (hopefully) helping to get base Julia working in the browser. @Keno and @SimonDanisch have compiled libjulia far enough so that it fails when it needs LLVM/codegen (the kf/wasm branch). This new platform may help get LLVM compiled, so that may help support codegen in the browser. I already have a version that compiles LLVM's basics using this platform and your LLVMBuilder. It'll also help by getting libraries like BLAS compiled to WebAssembly (it might have to be a basic BLAS).

Thanks for the EM_CONFIG option. I'll work on that. That'll help clean this up.

Understood on supporting the Emscripten issues. This will be experimental for a while, and depending on my time availability, things may stall at times.

Another issue I've run into is cmake builders. Emscripten comes with its own toolchain file, so it's in a different place. I can't think of a way to make it fit in the same place as others. Right now, this shard maps to /opt/x86_64-linux-gnu/. I tried mapping it to /opt/wasm32-unknown-emscripten, so I could copy the toolchain file to the same place as other platforms. But then the cache didn't work because it was read only. I didn't dig deeper.

I tried mapping it to /opt/wasm32-unknown-emscripten, so I could copy the toolchain file to the same place as other platforms. But then the cache didn't work because it was read only. I didn't dig deeper.

I'm not sure what you mean by "the cache didn't work". Which cache?

Emscripten’s cache which was in /opt/wasm32-unknown-emscripten/lib/emscripten-cache.

Ah, I see. You need a cache similar to the cache we provide for ccache; some persistent scratch space?

If so, you're going to need to add logic to mount a read-writable directory along with that shard. ccache is not associated with any particular shard, and so its logic is separate, but you basically want something like:

if platform_is_webasm
    push!(workspaces, webasm_cache_dir() => "/opt/wasm32-unknown-emscripten/lib/emscripten-cache"
end

Where webasm_cache_dir() can just be defined similarly to how we define ccache_dir(), and that will cause an appropriate persistent, read-write mapping to be mounted.

If you don't want the cache directory to be persistent, then we can just mount a tmpfs there within the bash setup script. Something like:

if [[ ${target} == *-emscripten* ]]; then
    mount -t tmpfs tmpfs /opt/${target}/lib/emscripten-cache
fi

You just need to make sure that directory exists first. ;)

Wow. Pretty cool. It is meant to be a persistent cache that's prepopulated.

I removed most of the clunkiness for the user.

• It has a .emscripten, so the user doesn't need to run emcc in a build script.
• The user doesn't need to install nodejs.
• The CMake toolchain is in the right place.

The internal items that are still clunky are:

• I crudely installed nodejs by hand from downloaded APK's (link). It'd be better to install this with the Rootfs.

• Emscripten tries to write a file next to the .emscripten file for "sanity checks". That fails because it's read only. I don't know that the sanity checks are that important. I couldn't figure out why the /opt/x86_64-linux-gnu/ directory is writable, but the /opt/wasm32-unknown-emscripten/ directory is read only.

• I have to use wget to pull in some sources because they have the same base name (here). When the first one is added to the downloads directory, it thinks it has the next one. For some files, the SHA is added to the front of the name, but it's only for some.

I played around with adding a cache directory to workspaces, but I ended up leaving it out.

It would be great to have this, one issue is that we need a fairly new LLVM version as a baseline. 8 might be barely new enough and things are enough in flux that I work of ToT.

Basically it would be great to start having the Julia dependencies available for a WASM build, e.g. BINARYBUILDER_TRIPLET=wasm32-unknown-emscripten

Agreed. I've been holding off on waiting for the dust to settle on the LLVM side and with Emscripten. Another piece changing is the WebAssembly System Interface (WASI and wasi-libc). That might be used with or without Emscripten.

Sidenote: it took me a bit to google ToT (tip of tree).

Sidenote: it took me a bit to google ToT (tip of tree).

Sorry LLVM-speak. Yeah WASI is rather interesting since that might simplify the bootstrapping issue quite a bit.

The problem with wasi is that I do think we want to bootstrap in a js environment, so we can do things like use the js native regex and BigInt rather than shipping gmp and pcre. Wasi and jsvm may just be different targets for us.

Python has dropped support for Emscripten, i.e.:

Name: wasm32-unknown-emscripten
Unsupported in: Python 3.13

switching to tier2 support for wasm32-unknown-wasi, so is that something Julia should also rather do?