Add back node.js 12.18.1 packages for Windows 7 support. #877
Conversation
|
For python we only require Python 3.6 today. For node its somewhat complicated. There is the version of node we use at build time, internally within emscripten (build version), and then there is the version of node we target and expect to be able to run on by default (target version). In general its probably good to keep the build version and the target version of node in sync, but if we have to hold back the build version for windows 7 that seems reasonable. Can I ask, do you users also expect to be able to run the resulting JS under the version of node that ships in emsdk or are they mostly targeting the browser? |
|
Can/should we be automatically installing/using this version of node on windows 7? Or do you have build scripts that can pull in specific versions when building your SDK? |
|
Do you have any idea who long your support for windows 7 will be required? |
|
Ops, sorry for the delay on this, your review fell through my email queue.
In order to support Windows 7, yes. The version of Node.js that we currently have actively refuses to run on Windows 7, but asks the user to upgrade to a newer Windows.
We run a custom install script that
Currently it looks like we need Windows 7 support until April 2022. After that I expect we won't need it anymore, since our LTS versions will rotate, and the next LTS won't support Windows 7 anymore. |
No, the users are always targeting the browser, but never running the Unity build outputs in Node.js. |
|
Ping, this would be good to get merged. |
* Improve emscripten-releases-tags.txt to support mutliple aliases (#837) Also, improve reporting of version resolution. e.g.: ``` $ ./emsdk install sdk-latest Resolving SDK alias 'latest' to '2.0.23' Resolving SDK version '2.0.23' to 'sdk-releases-upstream-77b065ace39e6ab21446e13f92897f956c80476a-64bit' Installing SDK 'sdk-releases-upstream-77b065ace39e6ab21446e13f92897f956c80476a-64bit'.. ... ``` * bugfix: allow to install SDK binaries alone (#834) * 2.0.24 (#839) * Error out on attempt to activate a missing tools (#838) Previously if a tool (any part of an SDK) was not installed we would issue a warning and continue to active without returning non-zero. This meant doing `emsdk install 2.0.0 && emsdk activate latest` would appear to be work aside from the warning messages about latest not being installed. This is especially annoying since we dropped support for side by side SDK installations. The following sequence is no longer valid and we want to make that clear by erroring out: ``` $ emsdk install 2.0.1 $ emsdk install 2.0.2 $ emsdk activate 2.0.1 ``` Since 2.0.2 replaces 2.0.1 on the filesystem the active here could fail hard rather than just warning. * Consistent error messages (#840) * Point zsh and csh users to the correct startup script (#843) Fixes: emscripten-core/emscripten#14446 * Print sys.argv when link_wrapper.py is invoked incorrectly (#847) This should help debug cases when the link_wrapper is not invoked correctly. * Support linking with `-o filename` (#849) When linking with `-o filename` (such as in various CMake build checks), the parameter passed to the linker is a temporary file, and it is passed as a bare filename (i.e. relative path without a `'/'`). In such cases, `outdir` would have been the empty string, and the final `tar` command would fail (actually the call to `subprocess.check_call(…)` is what fails). * 2.0.25 (#850) * 2.0.26 (#858) * 2.0.26-lto (#861) * 2.0.27 (#868) Includes LTO and non-LTO, with non-LTO as the default * 2.0.28 (#871) * Use `.json` extension for emscripten-releases-tags.json. NFC (#870) * Add LTO build for 2.0.28 (#873) * Small fix for Bazel instructions. (#875) In the past the instructions were to copy `emscripten_toolchain` into the project dir, now it downloads emsdk as a package so the `bazelrc` part has to refer to `@emsdk`. * Version 2.0.29 (#878) * 2.0.29-lto (#881) * Fix release name for 2.0.29-lto (#885) Fixes #884 * [Bazel] fix llvm bin path (#888) * Add arm64 fastcomp releases to emsdk_manifest.json (#891) This was missing from emsdk_manifest.json and should alow older fastcomp SDKs to be install on M1 apple hardware (in emulation mode). Fixes: #889 * 2.0.30 (#893) * Fix error handling: untargz() in emsdk.py (#895) Make untargz() in emsdk.py return False if tar command failed. * Fix passing -DLLVM_ENABLE_PROJECTS directive to CMake - it does not want to see double quotes in the field passed to it. (#898) * Fix emscripten-version parsing (#902) See emscripten-core/emscripten#15144 * 2.0.31 (#906) * bazel: pass -g instead of -g4 for wasm_asan feature (#904) * Add embind example to Bazel docs (#910) * Add embind example to Bazel docs * address feedback * Run buildifier on bazel/ (#913) * Update build_bazel_rules_nodejs to fix closure compiles (#912) * Update build_bazel_rules_nodejs to fix closure compiles * Fix spacing in update_bazel_workspace.sh script * space * 2.0.32 (#915) * Improve flags in bazel example (#917) * Add back node.js 12.18.1 packages for Windows 7 support. (#877) * Update CMAKE_OSX_DEPLOYMENT_TARGET from 10.11 to 10.14 (#924) Apparently 10.11 is no longer good enough to run the latest version of binaryen. Specifically since binaryen switched to using std::variant it now fails to build with this set to 10.11. This is also the version used on the emscripten-releases CI which builds the emsdk binaries: https://chromium.googlesource.com/emscripten-releases/+/refs/heads/main/src/build.py#673 * Revert "Update CMAKE_OSX_DEPLOYMENT_TARGET from 10.11 to 10.14 (#924)" This reverts commit 99e5e02. * 2.0.33 (#922) I add to temporarily disable the test_binaryen_from_source test under macOS to work around: WebAssembly/binaryen#4299 * 2.0.34 (#925) * Bump EmscriptenVersion to 2.0.34 * Fix bad edit Co-authored-by: Sam Clegg <sbc@chromium.org> Co-authored-by: Yulong Wang <yulong.fs@gmail.com> Co-authored-by: Attila Oláh <attilaolah@gmail.com> Co-authored-by: Attila Oláh <atl@google.com> Co-authored-by: Derek Schuff <dschuff@chromium.org> Co-authored-by: Danny B <danila.bespalov@gmail.com> Co-authored-by: Brad Kotsopoulos <bkotsopoulos@snapchat.com> Co-authored-by: Matt Gucci <matt9ucci@gmail.com> Co-authored-by: juj <jujjyl@gmail.com> Co-authored-by: walkingeyerobot <mitch@thefoley.net> Co-authored-by: Kevin Lubick <kjlubick@users.noreply.github.com> Co-authored-by: Larry Ewing <lewing@microsoft.com>
The current Node.js version 14.15.5 has unfortunately dropped support for Windows 7. At Unity we do still need to support that, so this PR adds back the earlier Node.js 12.18.1 packages.
Likewise, latest Python has dropped Windows 7 support, but using the (still existing) Python 3.7.4 works.
In the absence of any actual requirement to use newer Node 14, I would actually entertain the thought to go even further and revert back Node 12.18.1 as the default Node.js version, and the earlier Python 3.7.4 the default Python version, so that they will get unit tested.
Has Emscripten adopted any compile-time Node 14 or Python 3.9 requiring features? Ran the Emscripten test suite locally with this node.js & python version, which completed fine - so I suppose the answer is no. Would it make sense to fall back to these by default until April of 2022?