Just for reference: Obscure warnings about WSL2 or systemd whilst running gazelle on windows

[peakschris]

Just for reference: We were seeing obscure errors about wsl2 or sleeping to allow systemd to settle whilst running gazelle on Windows. It turns out this is due to forgetting to set the BAZEL_SH environment variable.

I am posting this reference to a fix already reported by @albertocavalcante to hopefully make the fix easier for future folks to find.

Posted by @albertocavalcante in #1309 (comment)

I was having the same issue on Windows even after v0.33.0.

C:\dev\workspace\chromed>bazel run //:gazelle
INFO: Analyzed target //:gazelle (100 packages loaded, 12313 targets configured).
INFO: Found 1 target...
Target //:gazelle up-to-date:
  bazel-bin/gazelle-runner.bash
  bazel-bin/gazelle
  bazel-bin/gazelle.exe
INFO: Elapsed time: 27.579s, Critical Path: 1.85s
INFO: 9 processes: 9 internal.
INFO: Build completed successfully, 9 total actions
INFO: Running command line: bazel-bin/gazelle.exe
/bin/bash: line 1: C:\Users\alber\_bazel_alber\pvqfizta\execroot\_main\bazel-out\x64_windows-fastbuild\bin\gazelle: command not found

It happens I am running on an Windows 11 machine with WSL2 setup, and Gazelle relies on the locally bash.exe which Bazel on Windows talks about.

So when WSL2 is setup, a bash.exe is created at C:\Windows\System32, which makes Bazel resolves to this, which actually runs in the WSL host and not the local Windows machine.

$ where bash
C:\Windows\System32\bash.exe
C:\Program Files\Git\usr\bin\bash.exe
C:\msys64\usr\bin\bash.exe

To fix this, make sure to set BAZEL_SH to either Git Bash or MSYS2 bash.

set BAZEL_SH=C:\msys64\usr\bin\bash.exe

set BAZEL_SH=C:\Program Files\Git\usr\bin\bash.exe

[peakschris]

Would it be possible to get gazelle to warn if BAZEL_SH is unset on windows?

[fmeum]

Sure, I don't really know what the right spot for this is. I don't have access to a Windows machine at the moment, but happy to review a PR.

[jayconrod]

For reference, the rules_go on Windows instructions are https://github.com/bazel-contrib/rules_go/blob/master/windows.rst. If you have msys2 already, I'm guessing you already found those.

Go msys2 is needed for cgo, but if you don't have any cgo code, it might not be necessary.

If I remember correctly, rules_go needs a little bash to build the builder tool, though maybe that's been migrated to a batch script already.

The Gazelle runner script still needs bash (template is internal/gazelle.bash.in). Seems okay to add a warning here if the bash running the script is not from msys2. Or it could potentially be translated into a batch script, or better, integrated into the Gazelle binary. It's mostly just setting environment variables and arguments.

I think a couple other things are needed elsewhere from msys2, at least patch for repository rules.