Emscripten generates bad path to node if cygwin is present and in PATH on Windows at first run.

[juj]

1. Delete the .emscripten file in C:\users\yourusername\ to simulate a 'first run' scenario.
2. Make sure that cygwin bin\ is in path, and that the 'which' tool is installed in cygwin (by default, it is)
3. run 'python emcc --help' to generate the .emscripten file.
4. Try running any of the tests or compiling any file with emscripten.

The result is

Running Emscripten tests...
warning: cannot check node version: [Error 3] The system cannot find the path specified
(Emscripten: Running sanity checks)
Checking JS engine /cygdrive/c/Program Files/nodejs/node failed. Check ~/.emscripten. Details: [Error 3] The system cannot find the path specified
FATAL: The JavaScript shell used for compiling (/cygdrive/c/Program Files/nodejs/node) does not seem to work, check the paths in ~/.emscripten

The result is that in .emscripten, the path to node is found using the 'which' tool inside cygwin, which generates something like

NODE = /cygdrive/c/Program Files/nodejs/node

However, when actually invoking node, the invocation is not done through cygwin, and calling '/cygdrive/c/Program Files/nodejs/node' is an invalid Windows path name and therefore fails.

There are some ways to fix this, I'm not sure which is the best at the moment:

1. Node lookup would always be done by assuming that node.exe is in PATH, and just always setting 'NODE=node' in .emscripten. Immediately, I can't spot a problem here, except than requiring the extra configuration from users to add node to PATH.
2. The lookup of node and the invocation of node is synchronized to always occur outside cygwin. This requires that the output of 'which' is routed through the cygpath tool to translate the cygwin path to a windows path. The usage is as follows:

C:\Users\clb>cygpath -w "/cygdrive/c/Program Files/nodejs/node"
C:\Program Files\nodejs\node

The output of cygpath would then get stored in .emscripten

1. The lookup of node and the invocation of node is synchronized to always occur inside cygwin. I'm not sure what this really entails, but I think it would require all calls to node throughout the emscripten codebase to first spawn a shell with 'sh' or similar, and have that shell execute node instead.

Option 3 sounds like a lot of work. I'd like emscripten to not require cygwin at all, so doesn't seem an interesting choice. Option #2 can be a bit odd actually, since doesn't 'which' just look through PATH for the path to the program? In that case, node must already be in path, and option 1 suffices.

Btw, does emscripten use 'which' in other parts of the codebase? In that case, I think each invocation of the command located by 'which' will break Windows, unless it explicitly does option 2 or 3.

[juj]

Oh, as a slight boost to option 1, perhaps on Windows .emscripten could read

NODE = os.path.expanduser(os.getenv('NODE') or 'node')

similarly to EMSCRIPTEN_ROOT and LLVM_ROOT. This would allow users not have NODE in PATH, but in a separate env variable NODE.

[juj]

As a workaround, to generate valid functional NODE= line in .emscripten after installing cygwin, I renamed cygwin\bin\which.exe to cygwin\bin\which_unused.exe which causes emscripten not to find it, and it falls back to just writing the line 'NODE=node' into .emscripten.

[kripken]

I am fine with whatever makes most sense for windows - to be honest I am not that familiar with normal practices on that platform.

I changed default .emscripten to contain

NODE_JS = os.path.expanduser(os.getenv('NODE') or '{{{ NODE }}}')

Should we also change {{{ NODE }}} to always be node on windows?

We don't use which anywhere but the automatic configuration stuff.

[juj]

This issue still persists, but it's minimal inconvenience for me, since emscripten now works fine for building without using cygwin at all.

As another workaround on Windows, one can do the first run without cygwin present, something like this:

set OLDPATH=%PATH%
set PATH=%PATH:cygwin=cygwin_unused%
emcc --help
set PATH=%OLDPATH%

That is what I automate on Windows buildbot since it needs to run some commands that need cygwin, and others that get confused by it.

[stale]

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