Skip to content

Conversation

@bulenty584
Copy link
Contributor

As discussed with @ryanking13, this pr automatically activates emscripten for users (e.g. running source emsdk.sh) and removes the need for them to do it manually. Changes are as follows:

Added activation and error handling in xbuildenv.py
Removed erroneous output after installtion in cli/xbuildenv.py

Previous PR was closed due to a branch mistake

bulenty584 and others added 17 commits October 15, 2025 15:39
  - Add new 'pyodide xbuildenv install-emscripten' command
  - Add clone_emscripten() method to clone emsdk repository
  - Add install_emscripten() method to install and activate Emscripten SDK
  - Add tests for new functionality
…in test_install_emscripten.py removed as well
1. Changed default version to `get_build_flag("PYODIDE_EMSCRIPTEN_VERSION")`
2. Updated `clone_emscripten` to `_clone_emscripten`
3. Removed and edited redundant tests in both new test files
4. Updated patch path in `xbuildenv.py` and added new command to CI workflow
Removed the get_build_flag command from xbuildenv cli and added default behavior as none
2. emsdk caching job removed in main.yml
3. install-emscripten help message also edited
2. Fixed pyodide-root to pyodide_root in integration tests
@ryanking13
Copy link
Member

ryanking13 commented Nov 4, 2025

Thanks for working on this @bulenty584! I have a few comments.

  1. Calling source inside a subprocess does not affect the local shell. If you see the emsdk_env.sh you can find that it uses the eval trick to set the env variable for the local shell.

  2. I am okay with running emsdk_env.sh after running install-emscripten command, but since it is volatile after the user closes the shell and reopens it, it would be nice to make a separate command for it, such as pyodide xbuildenv activate-emscripten.

  3. Actually, what I really prefer as a long term solution is to automatically adding emcc to the path when a user runs pyodide build or pyodide build-recipes without requiring the user to activate emcc manually. Of course, we can have both options (activating emcc explicitly or injecting path implicitly). But, the problem in (1) can be solved by storing the env variables as an internal variable in Python and passing them every time we call subprocess.

But you don't need to handle (3) in this PR. I am happy to accept this PR with (1) and (2) solved.

@bulenty584
Copy link
Contributor Author

Hey @ryanking13 so sorry I haven't been very active as I have had some midterms. I've been looking at the codebase to see how I could directly do #3 you outlined above. My question is exactly what is the problem? My understanding is the user must add relevant Emscripten env vars and adjust their path to point to the new emsdk but I am confused as to how adding emcc to their path achieves the same goal or functionality? Thank you!

@ryanking13
Copy link
Member

sorry I haven't been very active as I have had some midterms.

No worries :) We are all volunteers, and each person should work according to their own schedule.

My understanding is the user must add relevant Emscripten env vars and adjust their path to point to the new emsdk but I am confused as to how adding emcc to their path achieves the same goal or functionality?

What source emsdk_env.sh does is adding some env vars to the shell. We are also modifying the env vars that we pass to the subprocess call here. So if we update the env vars inside the Python code there, it basically has the same effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants