A few years ago, I wanted to use Bazel to build an old project of mine using Visual Studio 2017 Community.
Thing is, I don’t install most of MSVS on my system partition, as it’s on a relatively tiny SSD. So, where do I (portably) find it? And how do I set BAZEL_VS (per their documentation) to the correct path?
As I’m much more comfortable writing Bash scripts than writing old DOS-style Batch scripts, and as I’m going to have msys64 (or at least msys32) on my machines, clearly the answer is to write the resulting launcher in Bash. There are downsides to this approach, but it’s doable.
Do you even need this for Bazel?
No. I just tried running bazel-2.0.0-windows-x86_64.exe with my project. It found MSVS2019 out of the box both in cmd.exe and in the MSYS64 shell.
Unfortunately, I have a genrule that depends on bash, which didn’t work in cmd.exe even if I specified BAZEL_SH (missing binary for basename). And when I didn’t pass BAZEL_SH while running under MSYS64, it had trouble finding SDL/SDL.h presumably because the aforementioned genrule didn’t work.
Autodetection of MSVS2019 works, just set PATH Windows envvar to include msys binaries, and set BAZEL_SH Windows envvar to the output of cygpath -w /usr/bin/bash or cygpath -w /bin/bash.
You may want this for non-Bazel uses.
Finding Microsoft Visual Studio 2017
Assuming Bazel 2.0.0 is installed in C:\bazel under the default filename from the release on Github, this does the trick:
#!/bin/bash
# Based on https://superuser.com/a/539680 + searching around registry.
# Finds MSVS2017.
# Slashes when invoking 'reg query' are replaced with dashes because MSYS2.
VSPATH="$(cygpath -u "$(reg query 'HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7' -v 15.0 | tail -n+3 | head -n1 | awk '{for (i=3;i<=NF;i++) {printf "%s ",$i;};}' | sed 's/ *$//')")"
export BAZEL_SH="$(cygpath -w /usr/bin/bash)"
export BAZEL_VS="$VSPATH"
/c/bazel/bazel-2.0.0-windows-x86_64.exe $@
Finding Microsoft Visual Studio 2019
Unfortunately this is broken as of MSVS2019. See the explanation why that registry key is not used anymore.
The new situation is better: there’s a tool that does get installed in a well-known path: %ProgramFiles(x86)%/Microsoft Visual Studio/Installer/vswhere.exe.
The problem is merely that Bash doesn’t like parentheses in environment variable names, so ${ProgramFiles(x86)} won’t be acceptable. However, it was visible in env output! Other people have spotted the same thing, but as their writings talk about PROGRAMFILES(X86) in all caps, I’ve concluded that maybe it’s better to add the I flag to their sed-based solution.
#!/bin/bash
# Let's use VSWhere:
PROGRAMFILES_X86=$(env | sed -n s,'^PROGRAMFILES(X86)=',,pI) # because parens are not valid envvar names: http://mingw-users.1079350.n2.nabble.com/msysGit-bash-and-PROGRA$
VSWHERE=${PROGRAMFILES_X86}/Microsoft\ Visual\ Studio/Installer/vswhere.exe
VSWHERE="$(cygpath -u "${VSWHERE}")"
# Finding VC: https://github.com/microsoft/vswhere/wiki/Find-VC
VSPATH=$("${VSWHERE}" -latest -products '*' -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath)
export BAZEL_SH="$(cygpath -w /usr/bin/bash)"
export BAZEL_VS="$VSPATH"
/c/bazel/bazel-2.0.0-windows-x86_64.exe $@
VSCode
The problem with using Bazel integration into VSCode is that it wants a path to Bazel. But Bazel wants to have BAZEL_VS set.
Maybe I could work around this by writing a tool in a compilable language, then have it pass on all CLI arguments to actual bazel.exe, while also setting BAZEL_VS. Or maybe Bazel supports some settings in .bazelrc. I didn’t care to check. Instead, I’ve used msys2_shell.cmd as the ‘shell’ for the integrated VSCode terminal. I’m used to manually running Bazel and I don’t care enough about interactive debugging. For now, I just don’t care enough to properly integrate Bazel into VSCode on Windows (though it would be neat).
Why even bother with Windows?
I need to trivially compare networking traffic between my project and a third-party program. The third-party program is written for Windows; it would likely work on other platforms under Wine, but I don’t care enough to explore whether I can make a third-party binary patcher for that program work under Wine.
My program still works on Linux, built whether with Bazel or using Makefiles; but the deprecated SDL 1.2 was recently broken on macOS, my program won’t work on macOS.
Getting this to work is also a nice exercise.
–
via blog.vucica.net