Closure compiler breakage on windows emscripten-releases builder

[sbc100]

Since #9989 the emscripten-releases builder has been unable to roll the emscripten version.

The logs looks like this:

Error: EPERM: operation not permitted, mkdir 'C:\'
    at Object.mkdirSync (fs.js:806:3)
    at C:\b\s\w\ir\k\install\emscripten\node_modules\google-closure-compiler\cli.js:32:10
    at Array.reduce (<anonymous>)
    at mkDirByPathSync (C:\b\s\w\ir\k\install\emscripten\node_modules\google-closure-compiler\cli.js:29:24)
    at C:\b\s\w\ir\k\install\emscripten\node_modules\google-closure-compiler\cli.js:179:13
    at Array.forEach (<anonymous>)
    at C:\b\s\w\ir\k\install\emscripten\node_modules\google-closure-compiler\cli.js:178:32 {
  errno: -4048,
  syscall: 'mkdir',
  code: 'EPERM',
  path: 'C:\\'
}

https://chromium-review.googlesource.com/c/emscripten-releases/+/2026425

I tracked the problem down to a chain of different issues:

1. The emscripten-releases builder doesn't install the native version of the compiler (most likely because it doesn't find a compiler it likes at npm install time).
2. The default closure compiler decides to choose the JS version even thought java version is installed (Java doesn't seem be looked for in the path google/closure-compiler-npm#160)
3. The JS version seems to broken on windows which is the actual error we see (JS version failing on windows google/closure-compiler-npm#161)

[sbc100]

I don't think fixing (1) makes sense many of our users may be the same boat (i.e. no compiler visible at npm install time).

We can fix (2) by passing --platform=java on the command line, but I worry that we then can't pass things like -Xmx to the JVM like we used to. I'll upload a PR to try this solution. Fixing (2) upstream such that java version is only used when the native version is not found would also be better since then most users will still get the native version.

We can get (3) fixed upstream, but that obviously take time, and note that the JS version seems a lot slower so it would be sad if many of our users were stuck with it.

[juj]

Hmm, very odd.. when I run the suite locally on Windows, it does pass ok. Is there some specific tests/repro for you on Windows that causes the JS closure error?

[juj]

Something I wonder is if the emscripten-releases builder user has weaker privileges on the system? E.g. perhaps a regular admin user would receive EEXIST if attempting to mkdir C:, but a user that does not have privileges to modify C:\ would first get EPERM that overrides EEXIST, henc leading to the discrepancy that this issue is not occurring on regular(?) Windows systems.

[sbc100]

The bug only shows up IIUC when the JS backend is chosen. I imagine your windows machine building and installing the native version. You can force this by removing the native module from node_modules.

[juj]

Hmm, why doesn't the windows emscripten-releases builder choose the native version?

[sbc100]

My guess is that it fails to find a suitable compiler. Which is a good test, because that might be true of our users too. If we can make it fall back to JAVA rather than JS in such cases I think that would work. I think make setting JAVA_HOME will enable the fallback.