Bump emscripten to 3.1.34 #324
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…#1037) * [bazel] Set CLOSURE_COMPILER to workaround RBE+symlinks issue * space * specify node_js
* Optimize sandbox performance Link just the files needed to compile, link, or archive, rather than the entire directory tree. This drastically improves build times on macOS, where the sandbox is known to be slow (bazelbuild/bazel#8230). * Linux wants clang to link * all_files not needed? * Linux wants llc * And llvm-ar * Templated build_file_content
* Explicit outputs for wasm_cc_binary * Backwards compatibility * data_runfiles restore * restore test_bazel.sh * Using wrong path on accident * two separate rules for legacy support * Added name attribute to wasm_cc_binary rule
* 3.1.18 * Update LLVM include path in Bazel files
3.1.18 had a bad release binary on ARM64 Mac so push an updated version of the release.
Without this the recommended way to silence emsdk_env was to pipe its stderr to /dev/null.. but then you also loose potentially useful error message. Fixes: dotnet#946
12.2 is being deprecated
Newer versions of emscipten, starting all the way back in 1.39.13, can automatically locate the `.emscripten` config file that emsdk creates so there is no need for the explicit EM_CONFIG environment variable. Its redundant and adds unnessary noisce/complexity. Really, adding emcc to the PATH is all the is needed these days. One nice thing about this change is that it allows folks to run whichever emcc they want to and have it just work, even if they have configured emsdk. Without this change, if I activate emsdk and I run `some/other/emcc` then emsdk's `EM_CONFIG` will still be present and override the configuration embedded in `some/other/emcc`. e.g. in the same shell, with emsdk activated, I can run both these commands and have them both just work as expected. ``` $ emcc --version $ /path/to/my/emcc --version ```
fastcomp can only be install using explicit versions names so this name doesn't work.
Folks that want to work with fastcomp will now need to use an older checkout of emsdk.
This name existed to distinguish the SDK from fastcomp, but as of dotnet#1165, we no longer support fastcomp.
These function already returns a string.
* Add support for Visual Studio 2022 and migrate to using cmake --build when building on Windows. Leverage the VS2019 MSBuild 'Multi-ToolTask' feature CL_MPCount to saturate project builds properly to 100% CPU usage so building LLVM builds different cpp files in parallel. Clean up some code duplication around Visual Studio support. * flake * Work around Linux bot not having 'cmake --build . -j' flag.
…22, upstream LLVM has required VS2019 or VS2022 to build. So it has not been possible to build emsdk from source with VS2017 for a year. llvm/llvm-project@058c5df (dotnet#1178)
We have an existing `version_key` helper function for sorting versions.
It also does a better job, producing output like:
```
All recent (non-legacy) installable versions are:
3.1.31
3.1.31-asserts
3.1.30
3.1.30-asserts
3.1.29
3.1.29-asserts
```
Rather than:
```
All recent (non-legacy) installable versions are:
3.1.31
3.1.30
3.1.29
3.1.28
3.1.27
```
(with -assert versions listed after 3.1.0)
- Remove reference to `~/.emscripten`. We no longer use the home directory to store config information by default, either in emscripten or in emsdk. - Remove some references to `The Emscripten Command Prompt`. While I suppose this is referring to the windows-only `emcmdprompt.bat`, and I suppose it means "any shell where `activate` has been run", I think its more clear to simply avoid using the term.
…1189) If the user already has a version of node in their PATH don't clobber it. This doesn't effect emscripten since the version of node we use there is controlled via the config file, not via PATH. Part of fix for dotnet#705.
lewing
approved these changes
Mar 27, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.