When `emsdk install foo` would fail on Windows, the return code would
get ignored since there were later commands in the script file.
To fix that, capture the error code from the emsdk call, and output that
as the final return code.
Also a drive-by Python path fix, which seemed to be out of date in the
.ps1 file.
`C:\Python312\python.exe` is already in the path by default.
We no longer need to set this special path or environment variable. In
fact this code was doing nothing since it was adding the end of the PATH
so the system python was already coming first.
This migrates the bazel integration to the new Bazel dependency system
"bzlmod". bzlmod is becoming mandatory this year (see second sentence
here: https://bazel.build/external/migration).
This is a backwards incompatible migration, directly removing the old
WORKSPACE based approach. Users will have to change how they depend on
bzlmod, however I assume pretty much every user will be happy about it,
because they are forced to use bzlmod anyway or add extra flags to
continue to build with newer Bazel versions. Given that users normally
depend on specific git commits in the old system, they won't be hit with
this until they decide to upgrade emsdk.
The basic principle here is simple: I took everything that WORKSPACE did
and searched an alternative in bzlmod. Some interesting bits:
- We have less worries about multiple versions and people depending on
emscripten multiple times in different ways. This is resolved by the new
system: Bazel first iterates through the MODULE.bazel files recursively,
then finds the minimum version needed for each module and then executes
the module extensions that define repos exactly once at that version. So
no more ifs needed to detect multiple inclusions.
- A bunch of nodejs stuff moves to MODULE.bazel, because that is how the
nodejs module works now. As their module extension gets executed only
once you need to declare everything that you could need before that in
the MODULE.bazel file. A side effect of that is that we have to make a
fake repository when emscripten doesn't have an arm64 binary for linux,
because we can't actually figure that out in MODULE.bazel, so we have to
declare that it always exists and then create one in all cases.
There is a bunch of autoformatter changes in here as well, I could try
to revert them if you prefer.
Closes#1509
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.
This is a working solution for generating a separate Emscripten cache.
Note that this requires an additional entry in the workspace as follows:
```starlark
load("@emsdk//:emscripten_cache.bzl", emsdk_emscripten_cache = "emscripten_cache")
emsdk_emscripten_cache()
```
When used like this, the default Emscripten cache will be used. However,
if the entry is as follows:
```starlark
load("@emsdk//:emscripten_cache.bzl", emsdk_emscripten_cache = "emscripten_cache")
emsdk_emscripten_cache(flags = ["--lto"])
```
Then embuilder will be called to build all system libraries and ports
(i.e., the `ALL` option to embuilder) with the LTO option enabled. This
can take awhile, so I have also made possible to specify which libraries
you want to build explicitly:
```starlark
load("@emsdk//:emscripten_cache.bzl", emsdk_emscripten_cache = "emscripten_cache")
emsdk_emscripten_cache(
flags = ["--lto"],
libraries = [
"crtbegin",
"libprintf_long_double-debug",
"libstubs-debug",
"libnoexit",
"libc-debug",
"libdlmalloc",
"libcompiler_rt",
"libc++-noexcept",
"libc++abi-debug-noexcept",
"libsockets"
]
)
```
Resolves#807, resolves#971, resolves#1099, resolves#1362, resolves
#1401
This script is (IMO) more readable, but the real reason for this change is that
it raises an error message when the binary package fails to download. (The shell
script silently generated a bogus hash instead, because the shell's `set -e`
builtin does not affect commands executing inside a $() context.
It seemed just as easy to rewrite the script in Python as to fix that.
This change also updates some outdated filename references.
The first time around `node` was being correctly added to the PATH, but
the second time around this code was observing the emsdk copy of node
in the PATH and assuming it could be skipped.
Fixes: #1240
Newer versions of emscipten, starting all the way back in 1.39.13, can
automatically locate the `.emscripten` config file that emsdk creates so
there is no need for the explicit EM_CONFIG environment variable. Its
redundant and adds unnessary noisce/complexity.
Really, adding emcc to the PATH is all the is needed these days.
One nice thing about this change is that it allows folks to run
whichever emcc they want to and have it just work, even if they have
configured emsdk. Without this change, if I activate emsdk and I run
`some/other/emcc` then emsdk's `EM_CONFIG` will still be present and
override the configuration embedded in `some/other/emcc`.
e.g. in the same shell, with emsdk activated, I can run both these
commands and have them both just work as expected.
```
$ emcc --version
$ /path/to/my/emcc --version
```
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.
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.
* Makes provided bazel rules look up @emsdk workspace instead of local workspace
* Uses system-specific emscripten binaries instead of defaulting to linux
* Provides macros for loading emsdk dependencies (nodejs and emscripten binaries)
* Unhardcodes paths in bazel rules and .sh wrappers
* `update_bazel_workspace.sh` now updates `revisions.bzl`
* `emscripten_deps()` can be fed with specific emscripten version
* Adds external usage test
Addresses #650 and #696
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
