Moving forward with wasi-sdk vs WebAssembly/waterfall

[sbc100]

As mentioned in https://github.com/CraneStation/wasi-sysroot/issues/70 it might make sense to integrate or unify the two current efforts we have to build wasm sdk.

The https://github.com/WebAssembly/waterfall does have slightly different goals in that it primarily designed to all of our tooling together and tip of tree to warn is of breakages as soon as possible. wasi-sdk on the other hand pins its various dependencies and rolls forward periodically.

If we do decide to continue with two separate efforts, would it make sense to move this repo under WebAssembly org? Like we are planning to do wit the sysroot repo?

[sbc100]

For some background the waterfall is single python script that pulls in llvm (both upstram and fastcomp), v8, wasi-sysroot, libc++, libc++abi, compiler-rt, binaryen, emscripten, wabt all from ToT and tries to build from source and run bunch of tests. As part of that it produces and archive an SDK in tar and deb form.

My understanding is that this repo, by contrast pins each dependency as a git sub-module and builds a sysroot with single top level Makefile to produce a tar and deb archive. However my understanding of the setup here is limited (i've not actually run a build from here myself).

[pchickey]

Your understanding of the build is correct. This repo was developed out of necessity when we were trying to get wasi working before fixes were merged into LLVM and the sysroot was under rapid iteration. I never had enough spare cycles to integrate an actual CI service with this repo, so all testing and building of releases was done locally on our machines.

The real value of this repo, at this point, is that we can publish two packages: A. just the lib{c, c++, c++abi} that works with clang 8+, and B. a complete toolchain with clang, lib{c...} for end users. We use those downstream for https://github/fastly/lucet's dev environment & CI. As long as we make those available through the waterfall I'm happy. When I last looked at it, the waterfall publishes a ton of stuff in a single enormous deb, and I'd rather not use that downstream if the user only needs packaging A or B.

At them moment we use git tags to indicate what is "stable" - we don't make any real guarantees of stability but we do spot-check that it isnt broken. I am not familiar with how the waterfall works but as long as there's some way to indicate that a particular download is a recent, vetted release, we're satisfied. (I don't want downstream CI to break because waterfall packaged a broken clang, or something.)

[abrown]

Closing since waterfall is now defunct.