$VSWHERE

Okay, that's truly worth another "rongtudju" entry. I have to build with Visual Studio from times to times at the office, but I also work remotely from times to times. Of course, it's been ages since I installed sshd from mingw packages, and I'd rather call the build system from a ssh console when I'm remote than having GPUs trying to squeeze console activity into H.264 and show it on my screen. And it has been working happily for a good amount of years.

Then something bad happened, and as soon as the build system will try to invoke any of visual studio core programs, I would get error messages about

'cl' is not recognized as an internal or external command, operable program or batch file.

One key element of our build system is SCons, which I'm not fan of, but at least I can enter that and hack around now. Especially, I can see that no matter whether I set the $PATH environrment variable on the command line to include c:\program files\microsoft visual studio\...\bin\Hostx64\x64, the env['ENV']['PATH'] that scons will use to invoke the compiler will be empty.

If I decide to hack the 'CC' variable directly in Tools/msvc.py, I can make it compile stuff, eventually. But I had to dir /s stddef.h and others to get all those include path right. And it will stab me in the back as soon as I'll try to build a driver instead. Not to mention that of course, it doesn't help for other tools like lib.exe or link.exe ... 

A bit more rubber-duck-talking led me to VSINSTALLDIR hunting (and VS_VERSION hunting) in more python files, trying to find what is the normal way for SCons to decide which visual studio to use.

I know about the vcvarsall.bat script that "native developer console", but I doubt it would be used in a mingw-bash-scons-whatever-cl.exe setup, or at least not directly. And then, only then, I noticed the warning that the build tools had been trying to show me from the very beginning:

scons: warning: MSVC version '14.3' was not found.
  Visual Studio C/C++ compilers may not be set correctly.
  Installed versions are: ['14.0']

That was coming from Tool/MSCommon/vc.py, in a file that is mentioning $VSWHERE every now and then. Some more rubber-ducking and more dir /s revealed c:\program files x86\Microsoft Visual Studio\Installer\vswhere.exe ... and if I somehow force it into env['VSWHERE'], I no longer need to hack env['CC'] and env['AR'] to get a working build. Higgs! I even get the whole sub-project built just fine ^_^

Of course, the VPN dropped all my connections again a few minutes afterwards ... just enough to see whether I can get that running two times in a row, I guess...

Notes from the future:

• you may end up on a setup where your build script and your newly-installed Visual Studio do not agree where vcvarsall.bat should be. Copying it in another place will fail, as it is full of relative paths. But a trampoline calling "%~dp0\Auxiliary\build\vcvarsall.bat" %* does work
• you can set VSCMD_DEBUG=1 to see a bit more what is going wrong when you're loading vcvarsall
• only remotely related, but mind that you can end up with dotnet.exe installed in both Program Files and Program Files (x86). They'll ignore the SDKs installed by their counterpart. Unclear whether %__DOTNET_PREFERRED_BITNESS is of any help here ^^"
• just add export SCONS_MSCOMMON_DEBUG=- on your command line to see what vc.py is doing ... you should see it calling vswhere.exe -all -products * ... if that doesn't return some InstanceId, chances are hacking a path for env['VSWHERE'] won't be of any help. but before you give up, try defining $ProgramData;-)