594: Improvement cache in Windows r=syrusakbary a=syrusakbary
Caching was disabled on Windows, but can be re-enabled easily by improving the folder cache naming.
Reason why caching was disabled on Windows: We use a very long string (64 chars) for the wasmer version (hash). But we can use the version directly (no need to hashing)
Co-authored-by: Syrus Akbary <me@syrusakbary.com>
587: Use --enable-simd to control whether SIMD is enabled in the wasmparser. r=nlewycky a=nlewycky
Before this change, 'wasmer run --backend=llvm some-simd.wasm' would run without complaint.
Also, note that the flag is not part of the cache key, so after any successful run, we can run it again without passing the flag.
Co-authored-by: Nick Lewycky <nicholas@mxc.ca>
Co-authored-by: Nick Lewycky <nick@wasmer.io>
Co-authored-by: nlewycky <nick@wasmer.io>
Before this change, 'wasmer run --backend=llvm some-simd.wasm' would run without complaint.
Also, note that the flag is not part of the cache key, so after any successful run, we can run it again without passing the flag.
Building Wasmer is bit of a pain, because it requires Rust nightly, and
bunch of OS specific packages.
To make building easier, this adds a "build" script at the top-level
directory, which can be used to build Wasmer within a Docker sandbox
that has all the necessary dependencies installed. The build environment
is based on latest Ubuntu 19.04.
You first need to build a Docker image of the sandbox:
docker build --file Dockerfile.build --tag wasmer-build .
Then, to build Wasmer, run:
./build make
To test Wasmer, run:
./build make test
and so on.
You can also drop into a shell within the Docker with:
./build
The "build" script bind mounts current directory as "/wasmer" in the
Docker container, which allows inspecting the build contents like you
had built them on your local machine.
For future improvements, we should consider:
- Consolidation with existing Dockerfile (that is used for Circle CI)
- Publishing the build sandbox image on Docker Hub so that people
don't have to build it themselves
- Moving dependency installation to separate script, which can be
reused outside of the Docker sandbox.
The work has been inspired by "devtool" in the Firecracker project:
https://github.com/firecracker-microvm/firecracker/blob/master/tools/devtool
and "dbuild" in the Scylla project:
https://github.com/scylladb/scylla/blob/master/tools/toolchain/dbuild
Not handled here is @llvm.minnum and @llvm.maxnum which should be replaced with
@llvm.minimum and @llvm.maximum, but using those currently leads to LLVM backend
fatal errors.
