wasi-sdk 16.0 (new formula)

[cfallin]

WASI-SDK is a distribution of a custom libc (wasi-libc) with clang/LLVM
to target the WASI (WebAssembly System Interface) platform. WASI is a
definition of a POSIX-like set of syscalls for WebAssembly modules to
use. A program compiled for the wasm32-wasi target can run in various
WebAssembly-outside-the-browser environments (server-side, cloud/edge
computing, command-line runtimes like Wasmtime, etc) and within browsers
with the appropriate shims.

This formula is a fairly thin wrapper around the custom Makefile in the
wasi-sdk repository [1], which itself is a fairly thin wrapper around
an LLVM/Clang build with specific options and defaults together with a
build of the custom sysroot.

An alternative strategy might be to provide a formula that builds just
the sysroot (or downloads it as a tarball from the wasi-sdk releases),
depends on Clang from the clang formula, and provides some shell-script
wrappers that alter the default target and specify the sysroot. That is a bit
more work, however, and diverges a bit further from "upstream" (the SDK
as intended by its authors), so I wanted to get a reading on whether this
current approach might work first. Thanks!

[1] https://github.com/WebAssembly/wasi-sdk/

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[chenrui333]

linux build failure.

[cfallin]

Updated with @danielnachun's Linux build fix, and upgraded to wasi-sdk 16.0 (recently released). Builds fine locally for me (in 19m49s on an M1 Air 16GB).

[danielnachun]

Great! I or another maintainer can requeue this when one of our CI-long-timeout labels is free and get another run in to see if everything is working.

Regarding the question of whether this should use brewed clang or not, I'm personally okay with this building its own copy of clang but I'm not sure what other maintainers will think about this being keg-only because of conflicting file names. Most of the cases where we have keg-only formulae it's because the functionality is provided by macOS, or because it is a versioned formulae where we expect there to be conflicts but want to keep multiple versions installed simultaneously.

In this case it sounds like the intention is essentially provide a custom sysroot for clang, so as you said it could be possible to just install the sysroot and make some shell scripts to point brewed clang there. We should probably ask @Homebrew/core to weigh in here as this is a somewhat unique situation.

[carlocab]

If it's just to provide a custom sysroot, I'd like to avoid shipping another LLVM distribution. We can always wrap our existing binaries (or potentially even the macOS-provided clang) in wrapper scripts that configure the sysroot.

How far does the clang built here deviate from what we/Apple ship?

[cfallin]

OK, that's good to know and I'm happy to look more into that option! I'll ask over in wasi-sdk about the best way to do this and if there are any downsides (e.g. custom tweaks to LLVM, but afaik they don't carry any patches).

[danielnachun]

For reference, the custom Makefile they use is here: https://github.com/WebAssembly/wasi-sdk/blob/main/Makefile. From what I can see, for the main llvm build the only notable difference I can see is that DEFAULT_SYSROOT is changed to point to their custom sysroot.

However, looking at compiler-rt and libc++, there may be more substantial deviations. In libc++ it looks like they are disabling threading as aggressively as possible which I assume we and Apple don't do, and there are other parameters being set which we don't specify explicitly in the llvm formulae, nor do I know their values for macOS llvm. It would be great if upstream could articulate what flags they believe need to be set to non-default values and why. We don't natively support Windows at all in Homebrew, so anything being set for Windows compatibility is irrelevant to us.

It's also worth noting that the WebAssembly target should already be enabled in the llvm formulae because we enable all targets, and I'm guessing Apple has as well. So the question is whether they are setting flags for targeting WebAssembly that are mutually exclusive with our or Apple's LLVM tool chain.