|author||Derek Schuff <firstname.lastname@example.org>||Wed Mar 31 22:51:49 2021|
|committer||GitHub <email@example.com>||Wed Mar 31 22:51:49 2021|
Pass correct SDK path to build's setup_toolchain utility (#696) When using Chrome's hermetic toolchain, we also use a build infra utility to set up the environment variables that VS-compatible toolchains expect. Until recently one of the arguments to that script was irrelevant for us, but it recently became required (now the first argument points to the root of the toolchain package, and the 2nd sdk_path must be a subdir).
WebAssembly has many moving parts (implementations, tools, tests, etc) and no central owner. All of these parts have have their own owners, priorities, and tests (which include WebAssembly as well as others). A build and test waterfall allows us to test the interactions between these components. It helps us:
We should keep process to a minimum, try things out, see what works.
$ git clone https://github.com/WebAssembly/waterfall.git
depot_tools. Follow the instructions
pkg-configif you don't have it installed already, e.g.
# apt install pkg-config
Build.py has 3 types of actions:
Each of these types has multiple steps (e.g. a build step for each component). If you run build.py with no arguments, it will run all the sync, build, and test steps. If you make a change and only want to run a subset of steps, you can apply filters from the command line, via exclusions (to prevent specified steps from running) or inclusions (to run only the specified steps). Sync, build, and test exclusions are specified separately. For example:
$ src/build.py --no-sync --build-exclude=llvm
$ src/build.py --sync-include=wabt --build-include=wabt,binaryen --test-exclude=emtest,emtest-asm
The script should throw an error if you specify nonexistent steps or if you specify both includes and excludes for the same type of action.
When run, the script creates a directory
src/work inside the waterfall‘s git checkout. All modifications are made inside this directory (checking and out and building the sources, as well as the test builds and execution results). You can also use the git checkouts (e.g.
src/work/llvm) with your own branches; the sync steps will check out the latest revision from the script’s remote repositories but will not overwrite or destroy any local work.