vs-tool integration looks for $EMSCRIPTEN which is not set by emsdk activate

[MarkCallow]

The vs-tool integration uses $GccCompiler which it sets to "$EMSCRIPTEN¥emcc.bat" to find the compiler. However emsdk does not set this variable so when I attempt to build any project using the Emscripten platform in VC10 I get

"GCC compiler not found: emcc.bat"

Possibly related to the issue #1782. I.e, if the path was set correctly it would work.

[MarkCallow]

The path, though is not automatically set by "emsdk.bat activate." The VS integration should just work with whatever version was activated though. No further command should be necessary.

[MarkCallow]

"This" in comment #1 refers to $EMSCRIPTEN.

[MarkCallow]

If emsdk and vs-tool are truly to work independently of whatever other versions the user has installed and in his environment, then vs-tool needs to find emscripten, and the emsdk versions of clang, python, et al without reference to the users $PATH.

Currently I have had to add them all to my $PATH as well as adding EMSCRIPTEN to my environment in order to get a Visual Studio build to work.

[MarkCallow]

The variable set in .emscripten by "emsdk activate " is EMSCRIPTEN_ROOT. Should the VS integration be changed to that?

[juj]

The variable EMSCRIPTEN_ROOT= is an internal var to .emscripten, which vs-tool does not read. vs-tool reads the environment variable EMSCRIPTEN.

The upcoming 1.7.8 installer has been fixed to add an option "Add emsdk to PATH" in the installer, that sets the EMSCRIPTEN= environment variables automatically so that vs-tool sees it. Also there's a new command "emsdk_env" that sets not only PATH variables but also other env vars.

[MarkCallow]

I want to reopen this issue. How?

I just installed 1.12.0 and it failed to update the environment. 1.8.2 likewise had failed to update the environment and I had failed to check. I discovered on checking after activating 1.12.0 that EMSCRIPTEN was still set to 1.7.8.

Environment setting needs to be done automatically, not as an easily overlooked option. You can prompt the user if you are concerned about messing up their environment. If the user says "activate" some version they will expect that version to be used subsequently so a prompt shouldn't be necessary.

[juj]

Looks like a Windows-specific method could be possible via win32api python extension: http://stackoverflow.com/questions/488449/can-a-python-script-persistently-change-a-windows-environment-variable-elegant . I'll look into this.

[juj]

Ok, this should now be fixed for the next release, which is out soon. See emscripten-core/emsdk@2ed7a60 .

[juj]

This was fixed partially in 1.16.0, and now permanently in 1.21.0, see http://tiny.cc/2npmix