Fix windows SDK builds

[vvuk]

Tweak the Makefile to make things work under Windows. The assumption is that this will run under msys2 bash (i.e. git-bash), which seems to be where github CI will run it anyway. Removing that assumption would probably require not using Makefiles, and isn't really worth it.

There's also a "trigger on push to all branches" workflow thing in here that I can nuke before this lands, I needed it to test (and my final run is still running).

Fixes #39

[vvuk]

Fixed tar_from_installation to not hardcode the source build dir.

The final build on Windows is going to be much larger, because until recently, Windows didn't really support a useful form of symlinks so the llvm build process (probably due to cmake) just makes multiple copies to clang++, clang-cpp, clang-cl etc. This can be fixed on recent versions of Windows with developer mode enabled, but I don't know of any archive format that knows how to deal with this on Windows (ideally you could but symlinks in the archive, and it would create symlinks if they're supported otherwise just create a copy of the file).

[sbc100]

This is awesome! Thanks for working on it.

[sbc100]

Fixed tar_from_installation to not hardcode the source build dir.

The final build on Windows is going to be much larger, because until recently, Windows didn't really support a useful form of symlinks so the llvm build process (probably due to cmake) just makes multiple copies to clang++, clang-cpp, clang-cl etc. This can be fixed on recent versions of Windows with developer mode enabled, but I don't know of any archive format that knows how to deal with this on Windows (ideally you could but symlinks in the archive, and it would create symlinks if they're supported otherwise just create a copy of the file).

I think its fine if the windows build is larger in roughly the same way the a normal clang/llvm distribution is larger. In other words we shouldn't be trying to fix that problem downstream if they haven't yet addressed it upstream.

[vvuk]

So the only issue is that my last CI run died strangely (extra newlines added to log snippet):

-- Install configuration: "RelWithDebInfo"
-- Installing: C:/wasi-sdk/lib/clang/10.0.0/lib/wasi/libclang_rt.builtins-wasm32.a
"c:/wasi-sdk/bin/clang" -O2 -DNDEBUG --target=wasm32-wasi -fno-trapping-math -mthread-model single --sysroot="c:/wasi-sdk/share/wasi-sysroot" -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/headers/private -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/include -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src -MD -MP -o d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/build/libc-bottom-half/cloudlibc/src/libc/fcntl/posix_fallocate.o -c d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/libc/fcntl/posix_fallocate.c

# Install clang-provided headers.
cp -R d:/a/wasi-sdk/wasi-sdk/build/llvm/lib/clang c:/wasi-sdk/lib/

"c:/wasi-sdk/bin/clang" -O2 -DNDEBUG --target=wasm32-wasi -fno-trapping-math -mthread-model single --sysroot="c:/wasi-sdk/share/wasi-sysroot" -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/headers/private -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/include -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src -MD -MP -o d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/build/libc-bottom-half/cloudlibc/src/libc/poll/poll.o -c d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/libc/poll/poll.c

"c:/wasi-sdk/bin/clang" -O2 -DNDEBUG --target=wasm32-wasi -fno-trapping-math -mthread-model single --sysroot="c:/wasi-sdk/share/wasi-sysroot" -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/headers/private -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/include -Id:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src -MD -MP -o d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/build/libc-bottom-half/cloudlibc/src/libc/sched/sched_yield.o -c d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/libc-bottom-half/cloudlibc/src/libc/sched/sched_yield.c

cp: cannot create regular file 'c:/wasi-sdk/lib/clang/10.0.0/include/stdint.h': Permission denied
mingw32-make: *** [Makefile:88: build/compiler-rt.BUILT] Error 1
mingw32-make: *** Waiting for unfinished jobs....

...

/usr/bin/sh: c:/wasi-sdk/bin/clang: No such file or directory
/usr/bin/sh: c:/wasi-sdk/bin/clang: No such file or directory
mingw32-make[1]: *** [Makefile:364: d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/build/libc-bottom-half/cloudlibc/src/libc/stdio/renameat.o] Error 127
mingw32-make[1]: *** Waiting for unfinished jobs....
mingw32-make[1]: *** [Makefile:364: d:/a/wasi-sdk/wasi-sdk/src/wasi-libc/build/libc-bottom-half/cloudlibc/src/libc/sys/ioctl/ioctl.o] Error 127

I have no idea what happened here. It's almost as if c:/wasi-sdk just .. went away or otherwise got screwed? Each job time limit is 6 hours, so we're nowhere near that. Let's see what happens with the new one.

[vvuk]

Let's try without -j4. All that stuff in potentially parallel looks strange.

[vvuk]

Oh wait, that broken CI run was I think one of my own. This one succeeded! https://github.com/WebAssembly/wasi-sdk/actions/runs/82251119

(it was for the "trigger on push" commit that I just nuked)

[pchickey]

This is awesome, thank you for working on it!

Do you mind getting rid of the -j4 permanently? It has frequently tripped me up as well when debugging, and ninja does all of the useful parallelism.

[vvuk]

Done!

[pchickey]

Thanks so much! Will merge as soon as CI completes.

[sbc100]

I think the one place there the top level -j flag is useful was the $(MAKE) command for building wasi-libc.

This change would cause the build of wasi-libc to only use a single core. Maybe thats fine since it so small compared to llvm? Maybe we should has a -j4 the make command used internally to build wasi-libc?

[pchickey]

Ah, i forgot about that, and you are correct. I'll merge this and make a PR restoring that -j4.

[sbc100]

just looking that sizes, I wonder how mac manages to be so much smaller:

dist-macos-latest 42.3 MB
dist-ubuntu-latest 75.5 MB
dist-ubuntu-xenial 73.2 MB
dist-windows-latest 133 MB

[vvuk]

If you look at the build times with and without -j4:
ubuntu: with: 1h39m without: 1h40m
mac: with: 56m without: 56m

I'm not sure if it's doing much of anything, which makes sense because the the Makefile is largely serial. I'm guessing there's 1 or 2 steps that make decides it can parallelize, which causes problems because I /think/ it starts a build of some code that wants things like stddef.h before those things have actually finished copying over.

[vvuk]

Ah yeah -- compiler-rt and libc seem like they can run in parallel, and the end of compiler-rt does:

    cp -R $(ROOT_DIR)/build/llvm/lib/clang $(PREFIX)/lib/

which is going to overwrite files that clang is going to be reading from while libc is being built. It'll overwrite them with themselves so should be okay, but on Windows you can race on reading a file (permission denied) while it's being replaced, which matches the error I was seeing in CI.

[sbc100]

I'm not suggesting we use -j4 on the top level make command, just on the inner libc make command