How should external tools find emscripten?

[sbc100]

There are several external tools that want to be able to run emscripten (usually in order to run emcc/em++, etc). The ones that I know about are:

• cmake :

  emscripten/cmake/Modules/Platform/Emscripten.cmake

  Line 63 in ea3209a

  message(FATAL_ERROR "Could not locate the Emscripten compiler toolchain directory! Either set the EMSCRIPTEN environment variable, or pass -DEMSCRIPTEN_ROOT_PATH=xxx to CMake to explicitly specify the location of the compiler!")

• scons :

  emscripten/tools/scons/site_scons/site_tools/emscripten/emscripten.py

  Line 15 in ea3209a

  emscripten_path = os.environ.get('EMSCRIPTEN_ROOT')

• qtcreator: https://github.com/qt-creator/qt-creator/blob/ab36004fdc92ed0bc20d141d61c31237fbbfd8e4/src/plugins/webassembly/webassemblytoolchain.cpp#L65

The method that both scons used to use, and the qtcreator is currently using is to open the ~/.emscripten config file (which is in python format) and somehow parse out the value of EMSCRIPTEN_ROOT and use that.

Note that the EMSCRIPTEN_ROOT key is completely useless for emscripten itself since emcc and all the other tools in emscripten already know where they are when they are run. In fact the presence of this key can be confusing and contradictory (what does it mean if you run emcc and the EMSCRIPTEN_ROOT points to a different place?).

The method that cmake uses is to look for the EMSCRIPTEN environment variable. The scons tools were changed to be purely environment-variable-based a while back: #7249. It now looks for EMSCRIPTEN_ROOT in the environment.

qtcreator looks like its parsing the config file as an ini file, which I guess works in many cases.

As part of #9543 I would like to avoid having external tools try to parse the emscripten config file.

We should pick a single, recommended way to locate emscripten and implement that in all the tools. The options I see are:

1. Look for $EMSCRIPTEN to $EMSCRIPTEN_ROOT in the environment.
2. Look for emcc in the $PATH environment.
3. Create a new ~/.emscripten_root file that contains just a single string which is the emscripten directory.

We could also do (1) followed by (2), which I think is my preferred method.

The only downside of (1) or (2) is that it requires the user's environment variables to be changed.
With emsdk we already ask the user to run ./emsdk_env in order to do this, or to modify their startup files.

[bvibber]

I like 1) followed by 2) also; similar to setting CC or CXX it's easy to override when customizing or using an embedded environment, but doesn't need to be set at all when the default command is in the PATH.

The file-based method 3) can't be overridden on a project-by-project basis, and wouldn't get set for each user by system-wide packaging methods.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[sbc100]

I think this has still no yet been resolved fully.. tools like qtcreator and others are still a little confused about how to find emscripten correctly.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[agnickolov]

I see this issue still hasn't been resolved. Our little organization has a similar need. We specifically need to locate the path to the webidl_binder tool. May I suggest EMSCRIPTEN_ROOT to be made an official environment variable and have it be exported from emsdk_env. Then advise other distributions to also set it as part of their installers.

[sbc100]

@agnickolov we should really put webidl_binder and file_packager into the PATH. But for now you can find webidl_binder but looking up emcc in the PATH. e.g.

emcc = shutil.which('emcc')
webidl_binder = os.path.join(os.path.dirname(emcc), 'tools', 'webidl_binder')

[agnickolov]

It's a bit more complicated for our use case than that actually. We use vcpkg with Emscripten. Both rely on a CMake toolchain file. In order to get them to work together, we create our own CMake toolchain file that includes both. For that we need to locate the Emscripten toolchain file, hence the need for the Emscripten root. E.g. we need the value of the actual EMSCRIPTEN_ROOT variable, which we reference within our CMake toolchain file. The above suggestion should work in setting it up based on the location of emcc, at least on Unix-style OSes. On Windows (w/o WSL) we'll need to do something slightly different, but this is a starting point. I should also point out that we don't only use emsdk. On Windows we use chocolatey to set up Emscripten. So the solution should work with any Emscripten distribution, not only the official distribution via emsdk. Having EMSCRIPTEN_ROOT as an officially supported environment variable will help tremendously, but we can implement workarounds and set it up ourselves instead.

[sbc100]

Can you not derive the emscripten root from looking up emcc in the PATH?

This seems better than ask all emscripten users to not only put emcc in the PATH but also set EMSCRIPTEN_ROOT and importantly it avoids the issue of what do when EMSCRIPTEN_ROOT conflicts with the emcc in the PATH. In the past when we used EMSCRIPETN_ROOT it could be confusing if somebody set EMSCRIPTEN_ROOT to once value but then ran emcc from the different location. Using the PATH as the single source of truth seems like a good solution to me.

[sbc100]

Perhaps i'm not understanding something here. How would having EMSCRIPTEN_ROOT help tremendously in your case? Is looking up tools in the PATH hard in some place or system that I'm overlooking?

[agnickolov]

Unfortunately, this approach doesn't work with other distributions. I'm looking at the Homebrew installation on MacOS in particular, but I imagine others may use similar tricks as well. For starters, emcc on the path is a symbolic link. After following through the link, it leads to a wrapper script in a different folder that sets up Python and invokes the real script. I have no way of discovering the location of the real emcc that way.

[agnickolov]

I understand you don't officially support other distributions, but in the real world we need to deal with such issues...