This PR adds support for
`./emsdk install node-nightly-64bit`
which finds the latest nightly node.js version and installs that. It is
a moving target, so the next day when a new nightly is produced,
reissuing `./emsdk install node-nightly-64bit` will install the newer
published version.
Also, this PR adds a fixed 22.18.0 version for the cross compilation
s390x Node.js target as well. On an x64 Linux system, this allows
running
`./emsdk install node-big-endian-crosscompile-22.16.0-64bit`
to install the big endian Node.js. This greatly simplifies the steps at
https://github.com/emscripten-core/emscripten/compare/main...juj:emscripten:bigendian_test_suite#diff-c36b90121be240017fa490a1c00e63e47fa3235f5c1be0593e2b7502d017c778R9985-R10000
and enables a trivial way to switch between LE and BE Node.js versions
for testing.
CC @slavek-kucera
Update Python to 3.13.0 and add support to Windows on AMD64. Rewrite
packaging of pywin32 because it is no longer shipped via separate binary
installers, but has migrated to use pip.
Update Node from 18.20.3 LTS to 20.18.0 in precompiled releases. This
does have an effect of retroactively updating Node version also to old
releases, but this is expected to be fine.
Earlier Node 18.20.3 LTS did not yet support Windows on ARM64 builds.
Node 20.18.0 LTS is released on
https://nodejs.org/en/blog/release/v20.18.0.
This update currently only affects the "compiled from source" builds,
and not the Google precompiled releases.
Node v18 is that current LTS release of node and v18.20.3 is the latest
release of v18.
This change means that emsdk is no longer installable on Ubuntu/Bionic
18.04, and we now require Ubuntu/Focal 20.04.
See: #1183Fixes: #1173
This is a bit of a hack but I can't think of another way to do it.
Basically when downloading SDKs, we first try the new `.xz` extension.
If that fails, we fall back to the old `.tbz2`. Both these first two
download attempts we run in "silent" mode. If both of them fail we
re-run the original request in non-silent mode so that the error message
will always contain the original `.xz` extension.
See #1235
If the user already has a version of node in their PATH don't clobber
it. This doesn't effect emscripten since the version of node we use
there is controlled via the config file, not via PATH.
Part of fix for #705.
The newer versions of eslint require 14.17.0 or above. This
updates our node version to the latest in the 14.XX series.
I don't expect any user-visible changes.
* 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`
