Fix typo in `Tools/wasm/README.md` (GH-142426)
(cherry picked from commit 719d7960e2b55ab8310df3d9d69b7c9df3283fbf)
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Introduce `build-python` and `build-host` subcommands for `Tools/wasm/wasi` (GH-142266)
It should make it easier when you need to rebuild just the e.g. host Python, but it requires ./configure to run.
(cherry picked from commit 58e1c7a16f0926b1047c336eeed2849d5fff7c70)
Co-authored-by: Brett Cannon <brett@python.org>
Co-authored-by: Emma Smith <emma@emmatyping.dev>
Being more flexible in when not to explicitly set the sysroot when compiling for WASI (GH-142242)
(cherry picked from commit c5252045d3a7164f1829503d122091b5e469fda3)
Co-authored-by: Brett Cannon <brett@python.org>
Make printing log lines to the terminal a little cleaner when building WASI (GH-140772)
(cherry picked from commit abd19eddee20a7d05266f11f6042a84b04d29664)
Co-authored-by: Brett Cannon <brett@python.org>
GH-140768: Warn when the WASI SDK version doesn't match the supported version (GH-140769)
(cherry picked from commit 95a3564869daa3cc083e4d4603f5f03ee5f53e31)
Co-authored-by: Brett Cannon <brett@python.org>
GH-137484: Have `Tools/wasm/wasi` use the build triple instead of "build" (GH-37485)
This should help prevent issuse where something like a container is used to do one build and then someone tries to build again locally.
(cherry picked from commit 0953200b136bcb3293cc1bd57a062796ffcd529d)
Co-authored-by: Brett Cannon <brett@python.org>
Co-authored-by: Petr Viktorin <encukou@gmail.com>
GH-137243: Have `Tools/wasm/wasi` detect WASI SDK installs in `/opt` when the release tarball is extracted (GH-137244)
(cherry picked from commit 2f1a9f2ed498b3cb2dd5f4616bf3a07fd1ad074c)
Co-authored-by: Brett Cannon <brett@python.org>
Touch up `Setup.local` handling in `Tools/wasm/wasi` (GH-137051)
The comment in the generated file is now more self-explanatory. The checks for unexpected file contents are also strengthened.
(cherry picked from commit ec7fad79d24e79961b86e17177a32b32bb340fe5)
Co-authored-by: Brett Cannon <brett@python.org>
Co-authored-by: Zachary Ware <zach@python.org>
gh-128627: Use __builtin_wasm_test_function_pointer_signature for Emscripten trampoline (GH-137470)
With https://github.com/llvm/llvm-project/pull/150201 being merged, there is
now a better way to generate the Emscripten trampoline, instead of including
hand-generated binary WASM content. Requires Emscripten 4.0.12.
(cherry picked from commit 2629ee4eb0e9f66f28772cb4b4cc44ebe6de79ad)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
Basic support for pyrepl in Emscripten. Limitations:
* requires JSPI
* no signal handling implemented
As followup work, it would be nice to implement a webworker variant
for when JSPI is not available and proper signal handling.
Because it requires JSPI, it doesn't work in Safari. Firefox requires
setting an experimental flag. All the Chromiums have full support since
May. Until we make it work without JSPI, let's keep the original web_example
around.
(cherry picked from commit c933a6bb329bb97bc7e448388dad1b74f7ca4baa)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
Co-authored-by: Éric <merwok@netwok.org>
This is useful for implementing proper `input()`. It requires the
JavaScript engine to support the wasm JSPI spec which is now stage 4.
It is supported on Chrome since version 137 and on Firefox and node
behind a flag.
We override the `__wasi_fd_read()` syscall with our own variant that
checks for a readAsync operation. If it has it, we use our own async
variant of `fd_read()`, otherwise we use the original `fd_read()`.
We also add a variant of `FS.createDevice()` called
`FS.createAsyncInputDevice()`.
Finally, if JSPI is available, we wrap the `main()` symbol with
`WebAssembly.promising()` so that we can stack switch from `fd_read()`.
If JSPI is not available, attempting to read from an AsyncInputDevice
will raise an `OSError`.
(cherry picked from commit 7ae4749d064bd49b0dd96172fee20c1f1678d9e9)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
Reorganises the large Emscripten-specific file into the Emscripten folder.
(cherry picked from commit bbe589f93ccaf32eb95fd9d1f8f3dc9a536e8db1)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
To choose the node version we use. Together with:
https://github.com/python/buildmaster-config/pull/614
closes GH-136852.
(cherry picked from commit aec7f5f8b2e8b5e02869cdb4e1f8a9ef87c9f953)
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
Adds a note about flush/close on copyfileobj, and updates
the Emscripten build script to follow documented advice.
(cherry picked from commit 34393cbdd46fd965de86f1e7bc89ab111f506723)
Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
Modifies the behavior of the interpreter on crash under Emscripten:
1. No Python traceback shown on segfault/trap
2. The JavaScript source line is shown
The JavaScript source line is super long and completely unenlightening,
whereas the Python traceback is very helpful.
Moves the Emscripten web example into a standalone folder, and updates
Makefile targets to build the web example. Instructions for usage have
also been added.
This unifies the code for nodejs and the code for the browser. After this
commit, the browser example doesn't work; this will be fixed in a
subsequent update.
Add emscripten.py script to automate emscripten build.
This is modeled heavily on `Tools/wasm/wasi.py`. This will form the basis of an Emscripten build bot.
Eventually wasm32-wasi will represent WASI 1.0, and so it's currently deprecated so it can be used for that eventual purpose. wasm32-wasip1 is also more specific to what version of WASI is currently supported.
---------
Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>