-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Documentation] MacOS 10.15 beginner: docu not correct #14446
Comments
The "./" in the command line "./emcc --check" is needed when you are checking out emscripten from source and not necessarily adding to the path. I think this is the same for zsh and bash. Those instructions are for folks who are not using emsdk, but have emscripten checked out from git. I do think we could make it more clear perhaps? Perhaps if we instruct folks to add emscripten to their PATH first when we can skip the "./"? But I personally don't add emscripten to my PATH so there are at least some developers who won't want that. Alternatively we could change those commands to |
If you don't do anything else if you use
You should either use emsdk_env.sh or do this manual config yourself, but not both. Bear in mind if you do it manually rather then using emsdk_env.sh then your stuff could break if emsdk layout changes in the future. |
Thank you for your feedback, @sbc100 ! Does this mean i should NOT include the The message is shown every time a terminal window is started, which is disturbing. I assume that when I let the emscripten shell script do all the setup, that message will still appear each and every time, maybe even more verbose. Is there a reason why emscripten prints that message to the console? As for the use of './': The thing is that is fails when, as you say, the path is set. So it should be mentioned somehow, maybe a simple line would do: "Mac users (and Linux?): Keep in mind that './' is not needed when you add emsdk to your path variables." |
The |
The |
It looks like using |
I believe the I also believe that this is the reason we recommend using |
I moved I will deactivate emscripten, whenever I do not need it, but I would still like to ask you kindly to document a proper way how to keep emscripten quiet in zsh / oh-m-zsh. - Thank you! |
* 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>
Hi, dear emscripten guys!
I wanted to post my observations when installing emscripten on macOS Catalina, for which the explanations in the documentation are not correct (this very likely also concerns other macOS versions (and maybe even Linux?)). This might have to do with a version change that is not yet reflected in the docu (but since I am new to emscripten, I can't say).
Not sure if this is at all useful to you guys – if not, please close this issue. Thank you!
Reminder: With Catalina, zsh is the standard shell (not bash anymore).
My observation relate to mainly this page:
https://emscripten.org/docs/building_from_source/verify_emscripten_environment.html
To check emscripten installation, simply use
emcc --check
(not
./emcc --check
)To run a test, navigate to
cd upstream/emscripten/tests/
(not
cd emscripten/<version of emscripten you installed>
)and run
emcc hello_world.cpp
(not
./emcc tests/hello_world.cpp
)Important: While it is essential to remove
./
when usingemcc
, it is not essential with other commands (likeemsdk
, which works both ways).UPDATE
A follow-up question regarding zsh and environment variables:
Does emscripten actually support zsh? The reason I ask is that, as soon as I add
source ...emsdk/emsdk_env.sh"' >> $HOME/.zshrc
(NOT bash-profile), i keep getting this message:Setting environment variables: PATH=[...]
The message stems from emsdk.py (line 2727), which checks all kinds of shells, but not for zsh, and fires this message in the context of an error log. This is strange, because I actually did set the env vars and the folders via dot-files like this:
Why do I get an error?
The text was updated successfully, but these errors were encountered: