* Fix support for Apple M1. Node.js will still run via Rosetta 2 emulation since they do not yet have M1 support, but Python, LLVM, Emscripten and Binaryen will be native.
* Update M1 python version and URL
* Remove .gitignore additions
* Move python first in the manifest (#441)
* Use macosx-version-min when building python
* Update Intel macOS python package name
Now that all the components (binaryen, emscripten and llvm) use `main`
as the branch name is makes sense to give the SDK this name.
Keep backwards compat with the old name but issue a warning when its
used.
This avoids re-running the post-install scripts when commands such as
`./emsdk install latest` a re-run. This re-running of npm ci can be
significant slowdown especially during testing and developerment.
Becuase of the refactoring this change change also means we exit ealier
when a given tool fails to install. In general we want to error out as
early as possible on the first failure so as not to bury it.
For Java we use the value in the config file so it doesn't need to be in
the PATH.
For python, all our tools should launch via scripts that check for
EMSDK_PYTHON so having python in the PATH for emsdk users should not be
needed.
The motivation for this is that we don't want to clobber any existing
python or java versions that users might already have in their PATH.
This is the easy part of #705.
LLVM renamed their default branch to main from master.
This breaks builds of the SDK from the sources.
This commit retargets LLVM builds to use the git branch main when appropriate.
The version name "master" remains the same to maintain compatibility with existing build scripts
Fixes#692.
Binaryen renamed their default branch to main from master.
This breaks builds of the SDK from the sources.
This commit retargets binaryen builds to use the git branch `main` when appropriate.
The version name "master" remains the same to maintain compatibility with existing build scripts
Fixes#683.
This is still used for the legacy emscripten tags installation
but the native optimizer no longer exists on master.
This fixes `emsdk install emscripten-master-64bit`
The problem is that python can have trouble finding the default
certifcate set on macOS. The actual bundle is installed by the certifi
package which the requests module uses under the hood.
Fixes: #588
"Legacy" here meaning anything using only < 1.38.0, and anything
using 'nightly' mozilla builds (which have not been done for years).
This also lets us remove node 4.1.1 (but not 8.9.1).
Doing this for windows is trickier as we would also need to provide
the python binaries for win32.
Note that we don't provide node binaries in this case because the
node project itself doesn't produce 32-bit builds for linux anymore.
This should still be useable for 32-bit linux users although they
will need to provide their own node (or use the system provided
one).
Fixes: #470
* Add npm install step as post-build to Emscripten
* Address review
* Run npm install on releases-upstream and releases-fastcomp
* Fix node path
* Add node to PATH
* Only install production packages with npm
* Address review
* Build wasm upstream
* Fix lld build for wasm-ld. Add note about compiler-rt not working.
* Address review
* Address review
* Address review
* Address review
* If targeting fastcomp Clang, apply EMCC_WASM_BACKEND=0 so that previous leftover environment with EMCC_WASM_BACKEND=1 will not cause a conflict
* Add docs about setting up Emscripten
Without setting this, if a non-releases build was previously activated, it will keep affecting EMSCRIPTEN_ROOT in the emitted config file.
Helps with #326
This adds an "arch" field to various structures, so ARM and Aarch64
Linux can download appropriate versions of node and in theory
other tools, without trying to download x86 builds.
Since there are no prebuilt packages for clang and binaryen on ARM
or Aarch64 this will require building them, which can take a long
time, but works once installed.
Node 4.1.1 and 8.9.1 entries for ARM (armv7l) and aarch64 are
added, and the various x86/x86_64-only things are marked as such
to be filtered out on ARM machines.
Other downloads work as long as they don't have an arch specified,
which indicates they're expected to be arch-independent.
Does not yet fully work on ARM64 Windows (but works in WSL as the
Linux support is fine).
See WebAssembly/waterfall#542
The builds now contain lib/wasm-obj/ or lib/asmjs/ which have some cache contents. This places those in the cache so the user doesn't need to build them on first run, which for libc at least can be quite slow.
The mechanism here is to run emcc a first time in the emsdk. That clears the cache (since the emsdk just updated the .emscripten file). We can then safely place the files in the cache.
Note that FROZEN_CACHE is not used, since we do want to leave the user the option to build other things to the cache - we'll never ship all possible system and ports builds in the emsdk downloads, probably.
This contains a test, which passes on tot-upstream. The last tagged release doesn't have this yet.
