Without setting this, if a non-releases build was previously activated, it will keep affecting EMSCRIPTEN_ROOT in the emitted config file.
Helps with #326
This change moves the python code for emsdk into a file ending in .py.
This script is then run via emsdk.bat on windows or emsdk (a shell
script) on non-windows.
This avoid the #!/bin/sh at the top of the python script and the "exec"
hack on the first line that re-runs it under python. Hopefully this
preserves the intent of #273 without jumping through so many hoops.
The code for construct_env expects the output file to be at `argv[2]`,
but it is actually invoked in emsdk_env.{sh,fish} with $@ there
instead. Usually this is not a problem because the emdsk_env.{sh,fish}
is `sourced` directly from the user's shell and $@ is empty, but this
can break in scripted environments.
The $@ was added two years ago in 3b6c6b86 for no discernible reason,
but it was entirely ignored in the code until last month when #307
added a meaningful argument to construct_env but incorrectly kept the
$@.
This means that `./emsdk` works on UNIX system after emsdk self-updates
from a zip file. Without this one would need to run `python ./emsdk`
which seems to be why the tests were doing it this way.
Implements what @juj suggested here: #274 (comment)
After this, the behavior should consistently be: archives are downloaded, unpacked, then deleted immediately. Another install of the same thing will re-download.
Windows version of python 3 returns platform.machine() in upper case for AMD64 which wasn't being checked for so added .lower().
Doesn't affect Linux python3 which already worked.
This adds an "arch" field to various structures, so ARM and Aarch64
Linux can download appropriate versions of node and in theory
other tools, without trying to download x86 builds.
Since there are no prebuilt packages for clang and binaryen on ARM
or Aarch64 this will require building them, which can take a long
time, but works once installed.
Node 4.1.1 and 8.9.1 entries for ARM (armv7l) and aarch64 are
added, and the various x86/x86_64-only things are marked as such
to be filtered out on ARM machines.
Other downloads work as long as they don't have an arch specified,
which indicates they're expected to be arch-independent.
Does not yet fully work on ARM64 Windows (but works in WSL as the
Linux support is fine).
The user can choose which CMake generator to use by passing the --generator option, e.g. --generator=Ninja or --generator="Unix Makefiles" to emsdk.
Default on *nix systems is Unix Makefiles
See WebAssembly/waterfall#542
The builds now contain lib/wasm-obj/ or lib/asmjs/ which have some cache contents. This places those in the cache so the user doesn't need to build them on first run, which for libc at least can be quite slow.
The mechanism here is to run emcc a first time in the emsdk. That clears the cache (since the emsdk just updated the .emscripten file). We can then safely place the files in the cache.
Note that FROZEN_CACHE is not used, since we do want to leave the user the option to build other things to the cache - we'll never ship all possible system and ports builds in the emsdk downloads, probably.
This contains a test, which passes on tot-upstream. The last tagged release doesn't have this yet.
This verifies all builders successfully uploaded builds for a new version that we tag here.
This prevents a problem like happend on 1.38.35, where the mac and windows bots "skipped" the hash that we tagged - they built the one before, and I guess were too slow, so they skipped to the next commit after it? Which is expected I guess, but surprises me a little. Anyhow, with this fix we should avoid such problems in the future.
Tags 1.38.36 to verify things work and get people a working version.
Also check some other basic things: check the version built reports the right one in emcc -v, and that multiple emsdk updates still work.
This brings in the libtinfo changes. As a result this may fix breakage for some linux users, at the cost of some linux users possibly losing colors in the console (since sometimes that doesn't work with libtinfo not linked in).
Addresses emscripten-core/emscripten#8792
I've found what's the reason of the strange behaviour of last changes (#273).
In order to reproduce this problem it's needed:
To don't have python3 installed in system
To have pyenv with installed at least one version from each family, like:
pyenv install 3.7.0
pyenv install 2.7.15
To activate a version from python2
pyenv local 2.7.15
Then we have a strange situation that python3 is available as a command, but it's just a mock for pyenv:
➜ pyenv versions
system
* 2.7.15 (set by /home/trzeci/Projects/emsdk/.python-version)
3.7.0
➜ which python3
~/.pyenv/shims/python3
➜ python3 --version
pyenv: python3: command not found
The `python3' command exists in these Python versions:
3.7.0
➜ ./emsdk --help
pyenv: python3: command not found
The `python3' command exists in these Python versions:
3.7.0
As you see in an example above I didn't even call emsdk script, just tried to execute python3 --version and I've got exactly the same error. The problem of pyenv is that even if python3 isn't active it's available in the system PATH.
Calling ./emsdk --help get's the same error, as python3 was used.
At the moment this entirely breaks logic in python_selector and in pyenv working command is indistinguishable from stub python command.
@kripken: A couple of ways to go from here:
revert logic of python_selector and advertise mac users to use python3
keep logic and advertise pyenv users to use python3
This PR: extend logic of python_selector by checking if found python command is valid (for the instance by calling python --version), this will filter out false positive matches that coming from pyenv
After patch:
➜ pyenv versions
system
* 2.7.15 (set by /home/trzeci/Projects/emsdk/.python-version)
3.7.0
➜ which python3
~/.pyenv/shims/python3
➜ python3 --version
pyenv: python3: command not found
The `python3' command exists in these Python versions:
3.7.0
➜ ./emsdk --help
emsdk: Available commands:
emsdk list [--old] [--uses] - Lists all available SDKs and tools and their
current installation status. With the --old
....
As you can see python3 --version command fails as it was, but that's expected behaviour. What's important is that ./emsdk --help gets executed as python_selector recognizes a stub.
* Default Python 3 for running emsdk
On macOS it's pretty common to hit a problem
```
Error downloading URL 'https://github.com/kripken/emscripten/archive/1.38.25.tar.gz': <urlopen error [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:590)>
```
When an installation is started. I.e. `./emsdk install sdk-1.38.25-64bit` - this is caused in majority of cases by some problem of openssl and python2 - (some other https downloads work just fine, not sure why GitHub is special)
So this Pull Request will default Python to Python 3, for running `emsdk`. It does so by making ./emsdk executable in python, bash, and sh. In bash and sh it will run a python executor script, which picks the best python it can find, preferring python3 on non-windows.
The non-git case was not well documented and not tested, and it was broken since we switched the build infrastructure.
In the git case, an update is to do a git pull. In the non-git case, it downloads a zip and unpacks it. The old build infra apparently had builds created for this; instead, I made it download it directly from github. Perhaps we should consider creating builds for this as well eventually?
Also add a test for this, so we never break it again.
A bunch of info there is out of date.
Instead, let the link to the install instructions on the main site (which was there already on line 11 higher up) speak for itself; we should have just one central location for these basic instructions.
Also fix the can_be_installed which was always broken it seems - it returns True for success or a string for error, but didn't check if the output is True.
Includes a test, which hacks up emsdk to make it think it's on 32-bit, and verifies the error and message.
The output now looks like
===
The *recommended* precompiled SDK download is 1.38.34 (048cf9424790cc525a7ea6da340820aae226f3b9).
To install/activate it, use one of:
latest [default (fastcomp) backend]
latest-upstream [upstream LLVM wasm backend]
Those are equivalent to installing/activating the following:
1.38.34
1.38.34-upstream
All recent (non-legacy) installable versions are:
1.38.34
1.38.34-upstream
1.38.33
1.38.33-upstream
===
and after that is the detailed output with the older builds etc.
List the recommended downloads (latest, latest-upstream) first, and with version and hash. Then list precompiled things, then list build-from-source things.
Remove old upstream-clang build from source, which has been incorrect since llvm switched to a monorepo anyhow. If we want the emsdk to support source builds of llvm, we'll need to fix that - however, as we can use plain upstream llvm anyhow, that shouldn't be hard for developers to build themselves (and normal users will get a precompiled version anyhow).
Remove the option to build fastcomp from source with wasm backend support, as it is horribly old there.
Noticed these issues in emscripten-core/emscripten#8728
Keep the basic workflow test (checking what a user would do to get started) in bash, but otherwise it's more convenient for most tests to be in python.
