The action runs the existing create_release.py script in a new mode
created for github actions. Rather than using local git commands, it
uses a public action for creating a PR in the repository. The action can
be triggered from the website or via the CLI tool, for example
gh workflow run create-release.yml -R emscripten-core/emsdk -F
lto-sha=abc123 -F nonlto-sha=234567
Turns out this is what was causing the OOM when building binaryen since
we were clobbering the EMSDK_NUM_CORES environment variable by mistake.
See #1429
I faced the same issue mentioned in #1299, this PR fixes the issue by
taking in account specific `set` and `unset` syntax for Fish shell.
The post install instruction (i.e : `./emsdk activate latest`) provides
wrong instructions in Fish shell and Cshell cases.
This should be fixed by this PR too, although the code is a bit
redundant and it could be more cleaner.
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
On a Linux distro that doesn't have the `which` program installed we're
getting the following error:
$ ./emsdk install latest
./emsdk: line 39: exec: python: not found
It's failing to detect the installed `python3` and falls back to using
`python`, but this distro doesn't provide a python -> python3 symlink so
we fail.
Fix this by using `command -v` instead which is a POSIX standard.
The same change went into emscripten a couple years ago:
https://github.com/emscripten-core/emscripten/pull/15071
* Allows generation of audio worklet bootstrap js file
In order to allow users to generate the file, the allowed extension list in `link_wrapper.py` has been updated accordingly.
* adds audio worklet js to wasm_cc_binary too
---------
Co-authored-by: William Izzo <william.izzo@hey.com>
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
# Why
On one hand Ubuntu18's free LTS cycle is ended, and on the other hand Ubuntu18 does not support nodejs greater than v18.
# What's changed.
1. update the Linux Docker image to buildpack-deps:focal
2. some compatibility changes
3. use the new recommended way to install Docker ([see here](https://docs.docker.com/engine/install/ubuntu/))
See #1173
* (bazel) Set @platforms//os:emscripten for platform_wasm
* (bazel) Set @platforms//os:emscripten for platform_wasm
* (bazel) Set @platforms//os:emscripten for platform_wasm
This means that CI run that update `latest` actually test the thing
we are about to ship.
We recently had a case where `latest` was broken but `tot` was fixes
and we accidentally shipped a broken SDK version (#1353).
