These days this argument really means `install_even_if_directory_exists`
(at least since #9300.
However by the time we call `download_and_unzip` we have already checked
that `is_installed()` is false so we know we want to install for sure.
If the installation directory already existed and contained the correct
contents we would never get as far as `download_and_unzip`.
They were originally removed from emsdk_manifest.json in commit
12f1824ffb ("Remove Tools and SDKs
that do no longer work after migration from Mozilla to Google
hosting. (#395)").
Apparently 10.11 is no longer good enough to run the latest version of
binaryen. Specifically since binaryen switched to using std::variant it
now fails to build with this set to 10.11.
This is also the version used on the emscripten-releases CI which builds
the emsdk binaries:
https://chromium.googlesource.com/emscripten-releases/+/refs/heads/main/src/build.py#673
Previously if a tool (any part of an SDK) was not installed
we would issue a warning and continue to active without returning
non-zero.
This meant doing `emsdk install 2.0.0 && emsdk activate latest`
would appear to be work aside from the warning messages about
latest not being installed.
This is especially annoying since we dropped support for side
by side SDK installations. The following sequence is no longer
valid and we want to make that clear by erroring out:
```
$ emsdk install 2.0.1
$ emsdk install 2.0.2
$ emsdk activate 2.0.1
```
Since 2.0.2 replaces 2.0.1 on the filesystem the active here
could fail hard rather than just warning.
Also, improve reporting of version resolution. e.g.:
```
$ ./emsdk install sdk-latest
Resolving SDK alias 'latest' to '2.0.23'
Resolving SDK version '2.0.23' to 'sdk-releases-upstream-77b065ace39e6ab21446e13f92897f956c80476a-64bit'
Installing SDK 'sdk-releases-upstream-77b065ace39e6ab21446e13f92897f956c80476a-64bit'..
...
```
When we deactivate a tool we also want to remove its environment
variables. One driver for this is that modern sdks don't set
`EM_CACHE` whereas old ones did and we want to make sure that
`EM_CACHE` gets unset when folks upgrade (and then re-set if
they downgrade). See #797.
Previously this had to be
emsdk install sdk-releases-upstream-HASH
The only thing preventing using just the hash was that there was no
default for the backend, so defaulting to upstream fixes this. And then
we can do
emsdk install HASH
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.
Since #732 we lookup tot release dynamically, but we don't
necessarily want to do this for the `activate` command otherwise
`install` followed by `activate` a can fail if a new build was
produced inbetween.
Its not really very useful to cache the tot release in a local text
file. Instead just fetch the revsion each time `install tot` is run.
This avoids folks accidentally installing "old" tot releases.
Also, make the output a little less chatty when looking up tot version.
This is done by detecting the 40 character git sha in the SDK version
and creating a new set of tools based on this SHA. This works for any
command that uses expand_sdk_name (i.e. install activate and update) but
it wont show up in the output of `list`.
For example:
./emsdk install sdk-releases-upstream-b0cfdb236483b6828ee2e3f263fd94f011ed1863-64bit
Or just:
./emsdk install releases-upstream-b0cfdb236483b6828ee2e3f263fd94f011ed1863
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.
