-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Remove explicit support for JAVA and running closure compiler via java #20919
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
Conversation
0fbab35 to
d466694
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the default that is used if we don't specify which one? (And, is it different/slower than what we did before this PR?)
site/source/docs/building_from_source/verify_emscripten_environment.rst
Outdated
Show resolved
Hide resolved
The default is to use the native version of closure compiler. That is the only version we currently test. If folks want to do |
It should still be possible for a user to explictly run the java version of closure using `EMCC_CLOSURE_ARGS=--platform=java` or `--closure-args=--platform=java`, but this isn't something we need to have explict support for and its not something we test.
We use the native version of closure compiler these days so we don't need to install java on windows IIUC. See emscripten-core/emscripten#20919
We use the native version of closure compiler these days so we don't need to install java on windows IIUC. See emscripten-core/emscripten#20919
This is a partial revert of emscripten-core#20919. It turns out that we were still depending on falling back to the java version of closure compiler in some cases. Specifically, on macOS arm64 when Rosetta is not installed, we were falling back to the Java version since google-closure-compiler doesn't ship arm64 binaries. I imagine the same will be true of linux-arm64.
This is a partial revert of emscripten-core#20919. It turns out that we were still depending on falling back to the java version of closure compiler in some cases. Specifically, on macOS arm64 when Rosetta is not installed, we were falling back to the Java version since google-closure-compiler doesn't ship arm64 binaries. I imagine the same will be true of linux-arm64.
This is a partial revert of #20919. It turns out that we were still depending on falling back to the java version of closure compiler in some cases. Specifically, on macOS arm64 when Rosetta is not installed, we were falling back to the Java version since google-closure-compiler doesn't ship arm64 binaries. I imagine the same will be true of linux-arm64.
This change also reverts the changes made to test_other.py in emscripten-core#20919.
We use the native version of closure compiler these days so we don't need to install java on windows IIUC. See emscripten-core/emscripten#20919
We use the native version of closure compiler these days so we don't need to install java on windows IIUC. See emscripten-core/emscripten#20919
It should still be possible for a user to explictly run the java version of closure using
EMCC_CLOSURE_ARGS=--platform=javaor--closure-args=--platform=java, but this isn't something we need to have explict support for and its not something we test.