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`
* update bazel workspace for emscripten 2.0.3
* test to make sure WORKSPACE is up to date
* make it clear what happened when WORKSPACE is out of date
* intentionally add error to make sure circleci fails properly
* revert intentionally bad commit
* increase visibility of failure message
Co-authored-by: Mitch Foley <mitchfoley@google.com>
We no longer ship the sanify file as part of the SDK but
expect it be generated on first use:
https://github.com/WebAssembly/waterfall/pull/656
Also remove the Dockerfile itself from the docker image if
we include it then whenever you change anything in the
Dockerfile it invalides all the layers and forces a
completely rebuild. This makes iterating on the image
very slow.
- Copy the current checkout to the Dockerfile.
- Add .dockerignore to exclude files while copying.
- Test tip-of-tree build within CI.
- Run the test suite outside the Docker image.
- Perform extra sanity tests.
- Switch to make commands for CircleCI.
- Improve Docker README.
Fixes: #587
> If nodejs is not installed by `emsdk`, the output ".emscripten" file by `emsdk activate` will look like this.
>
> ```python
> NODE_JS = ''/usr/bin/nodejs''
> # too many quotes
> ```
>
> `emcc` fails to execute by this syntax error.
>
> I think fixing [this line](https://github.com/emscripten-core/emsdk/blob/1.40.1/emsdk.py#L1450) could be a solution.
>
> ```python
> activated_config['NODE_JS'] = "'%s'" % node_fallback
> # the value will be quoted later again
> ```
This change allows sourcing emsdk_env.sh from bash, zsh and
ksh.
The script works out the true location of the emsdk directory,
even if it is a symlink or the script itself is a symlink.
Added a test in scripts/test_source_env.sh to try sourcing via
all the shells and with various paths.
Co-authored-by: Bob Tolbert <bob@tolbert.org>
I think this is less surprising than continuing to support latest-fastcomp
with the last fastcomp release. That's technically correct - the last release
is 1.40.1, and always will be - but when a user asks for "latest" I think they
want something up to date. Instead, give a clear error that indicates how
they can get an actually up to date build, by using upstream.
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
- Remove unnecessary dependencies from build stage.
- Move binutils installation to first layer.
- Adjust indents and spacing.
- Merge ENV declarations into a single line.
- Split apt-get commands over multiple lines
TIL a couple of things about bat files. God help me.
- Use a single @echo off at the top rather than @ on every line
- Use lowercase names for builtin operation
- Use setlocal/endlocal rather than reseting EM_PYTHON at the end
* Improve activation message
The activation message is now IMHO more informative and
actionable:
```
$ emsdk activate latest
Setting the following tools as active:
node-12.18.1-64bit
releases-upstream-e7e39da9c81faecd9ecf44065cee864d76e4e34d-64bit
Next steps:
- To conveniently access emsdk tools from the command line,
consider adding the following directories to your PATH:
$HOME/wasm/emsdk
$HOME/wasm/emsdk/node/12.18.1_64bit/bin
$HOME/wasm/emsdk/upstream/emscripten
- This can be done for the current shell by running:
source "$HOME/wasm/emsdk/emsdk_env.sh"
- Configure emsdk in your bash profile by running:
echo 'source "$HOME/wasm/emsdk/emsdk_env.sh"' >> $HOME/.bash_profile
```
* .
embedded mode as been the default since #472 and I included
`--no-embedded` as an option during the interim time, but to simply
the code and avoid have two modes of operation I think its safe
to now remove the non-embedded mode.
This file should only ever exist momentarily. Its written during
`emsdk construct_env` on windows, but emsdk.bat immediately uses
at deletes it before returning.
Having this file remain around on disk would be a bug so we shouldn't
ignore its presense.
This was an internal script that we used to generate up
until #544. Now we avoid writing that file at all and
emsdk_env.sh is instead sourced directly.
This should fix the docker CI issues we have been having.
This is a because its not possible to determine the location
of as script that is currently being sources under a POSIX shell
such as dash (the default ubuntu shell). Only bash has this
special BASH_SCRIPT variable.
On platforms with no supported binary SDKs to download, find_sdk
can return None which caused a check in the "list" command to fail.
Checking for the return value before making method calls fixes this,
and allows Linux/ARM64 to run "emsdk list" and then build an SDK
from source.
Fixes https://github.com/emscripten-core/emsdk/issues/548
