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.
Without this, all releases are made available as fastcomp
versions.
Also, sort the releases to that the most recent come last.
This fixes the `emsdk list` display which only displays
the two most recent versions.
Using the full SDK name was causing a crash here because the
version is not of the form 1.2.3. e.g:
sdk-releases-upstream-3b8cff670e9233a6623563add831647e8689a86b-64bit
update-tags is called from two places `update-tags` itself and also
as as part of `update`. Silently ignoring the absence of git should
only happen in the later case. If the user explicitly ask for
update-tags we should hard fail as normal.
"emsdk install emscripten-master-64bit" is currently dependent on
whether emscripten node is installed or not.
This change allow using system-provided node / npm command to proceed
the installation. Also clarify the error message.
- Remove empty llvm-tags-32bit.txt
- Remove code that executes if llvm-tags-64bit.txt is missing (it
can't be since its checked in these days).
- Cleanup load_file_index_list
I verfied manually that llvm_precompiled_tags* list are identical
before and after this change.
This PR has three changes:
1) Fixing --permanent flag:
The previous algorithm looped over the values of PATH 4 times to check conditions while these conditions are the opposite of each other. Also, the result did not include all the parts in the whole_path.
I have combined these loops and fixed the algorithm, so no path is lost. Now using --permanent the PATH and Env variables are correctly updated.
2) Fixing --system flag:
Now, the system flag does not cause the PATH values to be overwritten/clobbered. The PATH/Env variables are correctly updated.
3) Fixing flagless flag:
When no flag is provided the value of process/shell is correctly updated and preserved.
This adds the tests for all the situations.
Fixes#634Fixes#645
Also switch PostMessage to SendMessageWithTimeout and only send one if
environment variables actually changed.
Also, enable and fix --permanent unit tests.
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
> ```
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.
* 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.
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
