strict cc = vcc ordering restriction in nim.cfg

[slomp]

I noticed that if I use cc = vcc in a nim.cfg file, the cc assignment has to happen before any other compiler flag listing, otherwise cl.exe can't be found by vccexe.

Example

This will not work:

noMain
nimcache:"nimcache"
cc = vcc

Current Output

vccexe.nim(61)           vccexe
osproc.nim(585)          startProcess
oserr.nim(66)            raiseOSError
Error: unhandled exception: The system cannot find the file specified.
; Additional info: "Requested command not found: \'cl.exe\'. OS error:" [OSError]

Expected Output

No special output expected.

Possible Solution

By having cc = vcc assignments happen before any other compiler switch, it works:

cc = vcc
noMain
nimcache:"nimcache"

Additional Information

This seems to affect only vcc; with other choices of compilers (I tested with gcc and clang), the order in which cc is specified/reassigned does not matter.

[Araq]

Very strange, I think cc = ... does cause an internal reset of some flags and that gcc/clang are not affected is merely a side-effect.

[demotomohiro]

@slomp
I tried to compile following test.nim with nim.cfg but I didn't get the error you got.
I tested with both Nim version 0.19.4 and 0.19.9 (latest devel) but they can find and call cl.exe.
I created nim.cfg and test.nim in the same directory.
My machine have Visual Studio 2013 and 2015 (and 2015 is used when cc = vcc). msvc version affect this bug?

nim.cfg:

noMain
nimcache:"nimcache"
cc = vcc

test.nim

echo "foo"

Could you tell me which version of Visual Studio and Nim installed on your machine?
In case you have multiple Visual Studios installed, tell me all.
If you run Nim with --listcmd option and copy&paste all outputs here might help to solve the problem.
(Nim call vccexe with different arguments when cc = vcc is placed before/after other compiler switchs?)

[slomp]

@demotomohiro
Thanks for looking into that.
I am running Visual Studio 2017, and it's the only VS installed (actual version is 15.9.7).
The cl.exe version is 19.00.24234.1.

Now, quite interestingly, it does work on my work machine!
I'll run with --listcmd from my home computer later on today and report the output.

[slomp]

It would seem the problem is a bit more subtle, and has to do with a @putenv latching even though it wa confined within an @if block that should not have "executed".
I'll see if I can get a clean, minimal reproducible case tomorrow.

[demotomohiro]

When you set cc = vcc, nim call vccexe.exe that setup PATH environment variable and call cl.exe.
vccexe.exe is a tool to call cl.exe even if vcvarsall.bat is not called and environment variables to call cl.exe are not set before you run nim.
But vccexe.exe doesn't support Visual Studio 2017, so PATH env variable need to be set correctly before you run nim.
(It uses environment variable like VS140COMNTOOLS to find vcvarsall.bat, but such environment variable is not set on VS2017)

When your Nim can work with cc == vcc switch, I think you run it from VS2017 x64 Native Tools Command Prompt, run vcvarsall.bat or set PATH variable yourself.
But when it doesn't, PATH variable is not correctly set.
Maybe you forget to run something or set PATH with wrong value.

Or maybe you installed VS2015 or older before. You uninstalled it, but environment variable VS140COMNTOOLS and vcvarsall.bat are left. vccexe.exe try to call cl.exe of old VS but not found.

[slomp]

Here's the minimal case:

Setup

• nim 0.19.4
• Visual Studio 2017 (actual version is 15.9.7)
• VS toolchains installed: v141, v140, v140_xp, LLVM-vs2014, LLVM-vs2014_xp
• cl.exe version (associated with the v141 toolchain) is 19.00.24234.1

test.nim

echo 42

nim.cfg (that works)

cc = vcc
nimcache:"nimcache"

@if gcc or clang:
    @putenv "PATH" "E:/Tools/MSYS2/mingw64/bin"
@end

Command Line

nim c test.nim

nim.cfg (that does not work)

nimcache:"nimcache"
cc = vcc

@if gcc or clang:
    @putenv "PATH" "E:/Tools/MSYS2/mingw64/bin"
@end

Note that only the order of cc = vcc line was changed.

The Error

"C:\WINDOWS\system32\cmd.exe" /C ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall" amd64 && SET"
cl.exe /nologo /DEBUG /Zi /F33554432 /FeC:\Projects\Lab\SandBox\nim2\test.exe C:\Projects\Lab\SandBox\nim2\nimcache\test.c.obj C:\Projects\Lab\SandBox\nim2\nimcache\system.c.obj
vccexe.nim(61)           vccexe
osproc.nim(585)          startProcess
oserr.nim(66)            raiseOSError
Error: unhandled exception: The system cannot find the file specified.
; Additional info: "Requested command not found: \'cl.exe\'. OS error:" [OSError]
Error: execution of an external program failed: 'vccexe.exe    --platform:amd64 /nologo /DEBUG /Zi /F33554432  /FeC:\Projects\Lab\SandBox\nim2\test.exe  C:\Projects\Lab\SandBox\nim2\nimcache\test.c.obj C:\Projects\Lab\SandBox\nim2\nimcache\system.c.obj '

My Conclusion

The @putenv command seems to be latching and setting the PATH when it should not (being that it has been predicated in the condition on gcc or clang). With PATH being essentially obliterated, whatever vcvarsall set seems to no longer apply, making cl.exe unreachable fro the expected PATH that vcvarsall initially configured.
I am not sure why specifying cc = vcc before the other compiler switches such as nimcache:... makes it work, and specifying after the switch makes the @putenv latch.