- Store Emscripten cache inside node_modules/.em_cache. Docker image ships without LTO libs, so Emscripten has to rebuild stdlibs on every build otherwise.
- Merge webp_enc + webp_dec build scripts. Core libwebp library is same in both cases, so there's no point in storing and building two copies of it.
* Add LTO for C++ builds
This didn't have much effect on fastcomp builds, but provides further size savings with new LLVM backend we switched to in #750 (and fixes the MozJPEG size regression from the same PR).
In the future we won't need to pass `--llvm-lto 1` explicitly, but latest Emscripten Docker image doesn't contain the Emscripten version with the necessary fixes for this.
* Delete build.log
Co-authored-by: Jake Archibald <jaffathecake@gmail.com>
We've been running each Make command in a single thread, resulting in fairly slow builds for C++ codecs.
This change instead runs all `make` invocations with `-j` defaulting to number of cores (retrieved via `nproc`).
On my machine Docker uses a VM configured to 4 cores out of 8 available. This change brings total build time for C++ codecs down from 10m28s to 7m5s (~3.5 minutes difference).
Note (1): I've converted imagequant builds to use built-in `make` as well to leverage this parallelisation and future-proof build script.
Note (2): we don't need to do the same for Rust, since Cargo parallelises builds by default.
Looks like we've been stuck on Emscripten fastcomp backend, misssing out on all new optimisations between LLVM 6 and LLVM 11 and going via slow asm.js pipeline when building.
This changes Docker images for Emscripten projects to point to emscripten-upstream instead and commits the updated artifacts.
This was a no-op in Wasm anyway. Now that I've added ability to control logging upstream, let's use it to disable it from compiled unit altogether for a slight win in size and perf.
