Gazelle fails to run on Windows

[filipesilva]

I am using Windows 10 and Bazel 0.17.1.

Following the steps in https://github.com/bazelbuild/bazel-gazelle#running-gazelle-with-bazel, on a new workspace, I get the following output:

$ bazel run //:gazelle --verbose_failures
INFO: Analysed target //:gazelle (34 packages loaded).
INFO: Found 1 target...
ERROR: C:/users/kamik/_bazel_kamik/mbmxo7xv/external/bazel_gazelle/internal/language/go/gen_std_package_list/BUILD.bazel:3:1: GoLink external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list.exe failed (Exit 1): link.exe failed: error executing command
  cd C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__
  SET CGO_ENABLED=1
    SET GOARCH=amd64
    SET GOOS=windows
    SET GOROOT=external/go_sdk
    SET GOROOT_FINAL=GOROOT
    SET PATH=C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64
  bazel-out/host/bin/external/io_bazel_rules_go/go/tools/builders/windows_amd64_stripped/link.exe -sdk external/go_sdk -installsuffix windows_amd64 -package_list bazel-out/host/bin/external/go_sdk/packages.txt -o bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list.exe -main bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a -- -extld C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe -w -extldflags /MACHINE:X64
external\go_sdk\pkg\tool\windows_amd64\link.exe: cannot open file bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a: open bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a: The system cannot find the path specified.
GoLink: error running subcommand: exit status 2
Target //:gazelle failed to build
INFO: Elapsed time: 2.381s, Critical Path: 0.21s
INFO: 0 processes.
FAILED: Build did NOT complete successfully
FAILED: Build did NOT complete successfully

I've created a repo the the bare minimum of code and files to reproduce this in https://github.com/filipesilva/gazelle-windows.

[filipesilva]

While the error says that the file below does not exist:

bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a

I can stat it:

stat bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a
  File: bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a
  Size: 13036           Blocks: 16         IO Block: 65536  regular file
Device: b6339ad8h/3056835288d   Inode: 562949955079282  Links: 1
Access: (0444/-r--r--r--)  Uid: (197609/   kamik)   Gid: (197609/ UNKNOWN)
Access: 2018-09-20 10:20:21.789736000 +0100
Modify: 2018-09-20 10:20:21.792735300 +0100
Change: 2018-09-20 10:20:21.814739300 +0100
 Birth: 2018-09-20 10:20:21.789736000 +0100

However, there is another referenced file that does not indeed exist:

$ stat bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list.exe
stat: cannot stat 'bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list.exe': No such file or directory

This file is listed on the runfiles manifest however:

__main__/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list.exe C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list.exe
bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list.exe C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list.exe

So perhaps the issue here is that the binaries are not availing of the runfiles lookup on Windows (https://github.com/bazelbuild/bazel/blob/master/tools/bash/runfiles/runfiles.bash#L15-L64)

Edit: nevermind, just realized the .exe is the output actually.

[filipesilva]

I played around with the path to the gen_std_package_list.a file. I noticed that if I put this file where the binary is ran, and edited the binary to use that path instead, the link.exe call was successful.

The directory from where these commands run is, in my machine (55 chars):

C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/

The original path to the file, which causing the missing cannot open file error, is (208 chars):

bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a

The longest path I could use that didn't show the error was (204 chars):

bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/abcdefgh/gen_std_package_list.a

Going to 205 chars by changing /abcdefg/ to /abcdefgh/ shows the error.

This got me thinking about the 256 path length limit in Windows.

There seems to be an issue about this in golang/go#18468, with a fix released in go1.11. Running bazel build @io_bazel_rules_go//:go_info shows I am already using go version go1.11 windows/amd64 so I guess that doesn't address the issue here.

So I had a second look at the path length. A 55+205=260 char path does not work but a 55+204=259 path does, so the 260 length seems to be the magic number.

bazelbuild/bazel#4550 mentions that MSYS (the bash that Bazel uses on Windows) supports a maximum of 260 characters, and that issue is marked as a duplicate of bazelbuild/bazel#4149.

That Bazel issue looks like it was resolved with the addition of the --experimental_shortened_obj_file_path=true flag in Bazel 0.13.0.

The option now seems to be deprecated and nothing seems to really change when using it:

$ bazel run //:gazelle --experimental_shortened_obj_file_path=true
WARNING: Option 'experimental_shortened_obj_file_path' is deprecated
INFO: Analysed target //:gazelle (0 packages loaded).
INFO: Found 1 target...
ERROR: C:/users/kamik/_bazel_kamik/mbmxo7xv/external/bazel_gazelle/internal/language/go/gen_std_package_list/BUILD.bazel:3:1: GoLink external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list.exe failed (Exit 1)
external\go_sdk\pkg\tool\windows_amd64\link.exe: cannot open file bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a: open bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a: The system cannot find the path specified.
GoLink: error running subcommand: exit status 2
Target //:gazelle failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.026s, Critical Path: 0.10s
INFO: 0 processes.
FAILED: Build did NOT complete successfully
FAILED: Build did NOT complete successfully

@meteorcloudy do you perhaps have some insight on this problem?

golang/go#17835 might also be relevant from the Go side.

[meteorcloudy]

Yes, this indeed is a long path issue again.

The --experimental_shortened_obj_file_path option only shortens object file path in C++ compilation. I am not very familiar with go rules, but I believe it's not affected by this flag.

I think there are generally two ways to address long path issue:

• Fix the tool to support long path. This might not be viable in this case, because looks like the go compile action also involves MSVC compiler, which doesn't support long path.
• Figure out a way to shorten the path exceeding the limit. This will only ease the problem, but it's the only way when the first solution is not possible. And I don't how hard it's going to be.

[meteorcloudy]

@jayconrod
Is it possible to shorten this path in go rules:

bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a: open bazel-out/host/bin/external/bazel_gazelle/internal/language/go/gen_std_package_list/windows_amd64_stripped/gen_std_package_list%/github.com/bazelbuild/bazel-gazelle/internal/language/go/gen_std_package_list.a

Do you think github.com/bazelbuild/bazel-gazelle/internal/language/go can be replaced by a shorter name, a hash value maybe?

[meteorcloudy]

FYI @filipesilva
I changed this line:
https://github.com/bazelbuild/bazel-gazelle/blob/993d887662ad83bb60b9ba1570270d4afcda91a1/internal/language/go/gen_std_package_list/BUILD.bazel#L12
to a shorter string
g/b/bazel-gazelle/internal/language/go/gen_std_package_list

Then the build works.
But not sure it's safe to make such change.

[filipesilva]

I can confirm that effecting that change will get past the long path roadblock:

D:\sandbox\gazelle-windows>bazel run //:gazelle
INFO: Analysed target //:gazelle (1 packages loaded).
INFO: Found 1 target...
Target //:gazelle up-to-date:
  C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle.bash
INFO: Elapsed time: 1.725s, Critical Path: 0.01s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Running command line: C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gINFO: Build completed successfully, 1 total action
/bin/bash: C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle.bash: No such file or directory

This now is a separate problem likely related to runfiles.

I don't think it's safe to change a Go importpath like this though... I think they are used for importing libraries within Go.

[jayconrod]

I think this should work now, but you'll need to update both rules_go and gazelle to tip of master.

As you have both found, Windows has trouble with long paths which are common in Bazel. Relative paths have some very low limit. Converting the path of the main .a file passed to the linker to an absolute path allows os.Open to perform some manipulation that allows longer path lengths. See fixLongPath if you're curious.

The other issue is that runfile symlinks aren't created on Windows, so the go executable isn't visible. I've updated the runner script to read the runfile MANIFEST if the symlink isn't present.

[filipesilva]

Heya @jayconrod, that was a really quick couple of fixes, thanks!

I updated https://github.com/filipesilva/gazelle-windows to use the latest tip:

http_archive(
    name = "io_bazel_rules_go",
    url = "https://github.com/bazelbuild/rules_go/archive/cbc1e32fba771845305f15e341fa26595d4a136d.zip",
    strip_prefix = "rules_go-cbc1e32fba771845305f15e341fa26595d4a136d",
    sha256 = "d02b1d8d11fb67fb1e451645256e58a1542170eedd6e2ba160c8540c96f659da",
)
http_archive(
    name = "bazel_gazelle",
    url = "https://github.com/bazelbuild/bazel-gazelle/archive/6d34b3ce6607023ed9626f42db1231df978332bd.zip",
    strip_prefix = "bazel-gazelle-6d34b3ce6607023ed9626f42db1231df978332bd",
    sha256 = "8b4c710c371dbbd132b46ea5cf15ab2d5aee265b78108c2bf62044f9629de3d6",
)

But I think I'm still running into an issue with runfiles:

D:\sandbox\gazelle-windows>bazel run //:gazelle
INFO: Build options have changed, discarding analysis cache.
INFO: Analysed target //:gazelle (40 packages loaded).
INFO: Found 1 target...
Target //:gazelle up-to-date:
  C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle.bash
INFO: Elapsed time: 8.612s, Critical Path: 4.38s
INFO: 33 processes: 33 local.
INFO: Build completed successfully, 42 total actions
INFO: Running command line: C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/g
INFO: Build completed successfully, 42 total actions
/bin/bash: C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle.bash: No such file or directory

Trying to debug atm.

[filipesilva]

I think the first issue is https://github.com/bazelbuild/bazel-gazelle/blob/6d34b3ce6607023ed9626f42db1231df978332bd/internal/gazelle.bash.in#L1

I've seen this problem before in rules_nodejs and there we use #!/bin/bash instead. Unsure of all the implications though.

Changing this allows the script processing to progress and shows a couple more errors:

D:\sandbox\gazelle-windows>bazel run //:gazelle
INFO: Analysed target //:gazelle (0 packages loaded).
INFO: Found 1 target...
Target //:gazelle up-to-date:
  C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle.bash
INFO: Elapsed time: 1.185s, Critical Path: 0.01s
INFO: 0 processes.
INFO: Build completed successfully, 2 total actions
INFO: Running command line: C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gINFO: Build completed successfully, 2 total actions
C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle.bash: line 74: grep: command not found
C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle.bash: line 74: head: command not found
C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle.bash: line 74: cut: command not found

I think this happens when the binary is not actually compatible with Windows and isn't hooked up to use MSYS through Bazel. It's still a .bash file, and it should instead be a .exe.

sh_binary should take care of this, when used, I'm not sure of go_binary is doing the same, but I can't find a mention of sh_binary being used in https://github.com/bazelbuild/rules_go.

@jayconrod should I open a new issue with these newly surfaced problems, or would you prefer to reopen this on?

[jayconrod]

#324 should fix the first issue. Please try it out and let me know if it works for you.

A contributor changed #!/bin/bash to #!/usr/bin/env bash because NixOS doesn't put bash in a standard location. But Windows doesn't observe shebang lines anyway. Bazel will tell it to execute the script directly, and that only works for .exe, .bat, and a few other formats. Wrapping the script in an sh_binary fixes this. Bazel knows to use BAZEL_SH when invoking shell scripts.

About the other missing executables: I'm not able to reproduce that. It sounds like they aren't in PATH. PATH should be set in the msys .bashrc file though.

I fixed a couple other problems I noticed. bazel run doesn't seem to report errors when the script exits abnormally (due to set -e), so I thought it was working before when it really wasn't.

[filipesilva]

@jayconrod tried with your commit:

$ bazel run //:gazelle
Starting local Bazel server and connecting to it...
INFO: SHA256 (https://github.com/bazelbuild/bazel-gazelle/archive/4c94784d65bc84a2b15a676e2e04d7300cb003b0.zip) = aa72267ceaf037ae78d945c683b6ecbf03bdf4ddae2715421c5bab00eabb75a8
INFO: Analysed target //:gazelle (41 packages loaded).
INFO: Found 1 target...
Target //:gazelle up-to-date:
  C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle-runner.bash
  C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle
  C:/users/kamik/_bazel_kamik/mbmxo7xv/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/gazelle.exe
INFO: Elapsed time: 25.196s, Critical Path: 0.38s
INFO: 0 processes.
INFO: Build completed successfully, 6 total actions
INFO: Build completed successfully, 6 total actions

Finishes successfully!

I think the other missing executables were just because native.sh_binary was not being used.

I also tried it on another repository (the main one where this came up, https://github.com/bazelbuild/rules_typescript), and it also seems to have run successfully:

$ bazel run //:gazelle
INFO: Build options have changed, discarding analysis cache.
INFO: Analysed target //:gazelle (39 packages loaded).
INFO: Found 1 target...
Target //:gazelle up-to-date:
  C:/users/kamik/_bazel_kamik/5c2rzegw/execroot/build_bazel_rules_typescript/bazel-out/x64_windows-fastbuild/bin/gazelle-runner.bash
  C:/users/kamik/_bazel_kamik/5c2rzegw/execroot/build_bazel_rules_typescript/bazel-out/x64_windows-fastbuild/bin/gazelle
  C:/users/kamik/_bazel_kamik/5c2rzegw/execroot/build_bazel_rules_typescript/bazel-out/x64_windows-fastbuild/bin/gazelle.exe
INFO: Elapsed time: 24.003s, Critical Path: 6.55s
INFO: 23 processes: 23 local.
INFO: Build completed successfully, 24 total actions
INFO: Build completed successfully, 24 total actions
gazelle: multiple rules (@build_bazel_rules_typescript//examples/protocol_buffers:tire_proto and @build_bazel_rules_typescript//examples/protocol_buffers:rules_typescript_proto) may be imported with "examples/protocol_buffers/tire.proto" from @build_bazel_rules_typescript//examples/protocol_buffers:rules_typescript_proto

Great work!

[jayconrod]

Awesome, glad it works for you! To be honest, I expected to have to jump through more hoops to get this working. Bash scripting on Windows, especially through Bazel, is a bit hairy.

[filipesilva]

Indeed! We're doing a big push towards Windows compat so we're trying to get all of the Angular repos to build correctly on windows, loads of stuff like this comes up. Runfiles lookup, bash scripting, and path separators are the biggest culprits.

[meteorcloudy]

Wow, this is awesome! Do we have any test for gazelle on CI? If so, can we add a job to guard the Windows build?

[filipesilva]

Trying to run gazelle remotely on our Windows CI (bazelbuild/rules_typescript#280) seems to reveal another problem:

bazel run --curses=yes --color=yes --verbose_failures //:gazelle
INFO: Analysed target //:gazelle (39 packages loaded).
INFO: Found 1 target...
Target //:gazelle up-to-date:
  C:/users/b/_bazel_b/5nhylkm4/execroot/build_bazel_rules_typescript/bazel-out/x64_windows-fastbuild/bin/gazelle-runner.bash
  C:/users/b/_bazel_b/5nhylkm4/execroot/build_bazel_rules_typescript/bazel-out/x64_windows-fastbuild/bin/gazelle
  C:/users/b/_bazel_b/5nhylkm4/execroot/build_bazel_rules_typescript/bazel-out/x64_windows-fastbuild/bin/gazelle.exe
INFO: Elapsed time: 15.507s, Critical Path: 3.70s
INFO: 33 processes: 33 local.
INFO: Build completed successfully, 44 total actions
INFO: Build completed successfully, 44 total actions
/usr/bin/env: 'bash': No such file or directory
Traceback (most recent call last):
  File "bazelci.py", line 1392, in <module>
    sys.exit(main())
  File "bazelci.py", line 1379, in main
    monitor_flaky_tests=args.monitor_flaky_tests)
  File "bazelci.py", line 412, in execute_commands
    execute_bazel_run(bazel_binary, config.get("run_targets", None))
  File "bazelci.py", line 724, in execute_bazel_run
    "--color=yes", "--verbose_failures", target])
  File "bazelci.py", line 962, in execute_command
    return subprocess.run(args, shell=shell, check=fail_if_nonzero, env=os.environ).returncode
  File "C:\python3\lib\subprocess.py", line 418, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['bazel', 'run', '--curses=yes', '--color=yes', '--verbose_failures', '//:gazelle']' returned non-zero exit status 127.

The crux of it seems to be /usr/bin/env: 'bash': No such file or directory.

Not sure why this wasn't revealed locally. I tried running bazel run //:gazelle from within both CMD and gitbash and got successful runs.

[meteorcloudy]

I think maybe on your Windows CI, you don't have bash binary in PATH?

[filipesilva]

@meteorcloudy probably not, but should I? I don't think that's a part of the Windows setup for Bazel.

I tried to make a basic shell script that has echo $PATH, and running it via sh_binary.

Checking on my gitbash shell, I have these environment variables:

/usr/bin
/c/Program Files/Git/mingw64/bin
/c/Program Files/Git/usr/bin
/c/Users/kamik/bin
/c/Users/kamik/bin
/c/Program Files/Git/mingw64/bin
/c/Program Files/Git/usr/local/bin
/c/Program Files/Git/usr/bin
/c/Program Files/Git/usr/bin
/c/Program Files/Git/cmd
/c/Program Files/Git/usr/bin
/c/Program Files/ConEmu/ConEmu/Scripts
/c/Program Files/ConEmu
/c/Program Files/ConEmu/ConEmu
/c/Program Files/Docker/Docker/Resources/bin
... my other system paths

And on CMD I have

/usr/bin
/c/Program Files/Docker/Docker/Resources/bin
... my other system paths

This makes sense since /usr/bin is the MSYS2 bin dir, and locally I can see that /usr/bin/bash.exe exists. It's worth noting that /usr/bin is not present on my when I print it from CMD outside of bazel.

On my CI run I saw:

/c/python3/Scripts
/c/python3
/c/Windows/system32
/c/Windows
/c/Windows/System32/Wbem
/c/Windows/System32/WindowsPowerShell/v1.0
/c/Windows/System32/OpenSSH
/c/ProgramData/GooGet
/c/Program Files/Google/Compute Engine/metadata_scripts
/c/Program Files (x86)/Google/Cloud SDK/google-cloud-sdk/bin
/c/Program Files/Google/Compute Engine/sysprep
/c/ProgramData/chocolatey/bin
/c/Program Files/Git/cmd
/c/openjdk/bin
/c/Program Files (x86)/Windows Kits/8.1/Windows Performance Toolkit
/c/bazel
/c/buildkite

Seeing that there is no /usr/bin here, I'm not surprised bash can't be found.

But I am surprised that /usr/bin is not there, since I expected it to be added by Bazel. The Windows CI we use is running Bazel 0.16.1 while locally I am running 0.17.1.

I tried using Bazel 0.16.1 locally and can see that /usr/bin is now missing as well, which explains why bash (and I suppose other MSYS2 binaries) cannot be found in the CI.

On rules_typescript we use the https://github.com/bazelbuild/continuous-integration setup, so I'd say it we need to make sure it's updated to 0.17.1 to fix binary issues on Windows.

[meteorcloudy]

Indeed, just realized the fix bazelbuild/bazel@7aaa34a is not included in 0.16.1
I'll tell our CI team to upgrade bazel to 0.17.1 ASAP

[veqryn]

@filipesilva @jayconrod How did you all solve the gazelle.bash: No such file or directory error?

I am using the latest 0.21.0 version of Bazel for windows, I have MSYS installed and the BAZEL_SH env var set pointing to it, yet I get the following error:

PS C:\Users\xxxxxxx\workspace\go\src\github.com\ReturnPath\xxxxxxxx> bazel run //:gazelle
WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
c:\users\xxxxxxx\workspace\go\src\github.com\returnpath\xxxxxxxx/.bazelrc
INFO: Invocation ID: 9860c68c-4bb3-45af-b4a7-2a1c537ad1f0
DEBUG: C:/users/xxxxxxx/_bazel_xxxxxxx/445idx3f/external/bazel_skylib/lib.bzl:30:1: WARNING: lib.bzl is deprecated and will go away in the future, please directly load the bzl file(s) of the module(s) needed as it is more efficient.
INFO: Analysed target //:gazelle (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //:gazelle up-to-date:
  C:/users/xxxxxxx/_bazel_xxxxxxx/445idx3f/execroot/com_returnpath_xxxxxxxx/bazel-out/x64_windows-fastbuild/bin/gazelle.bash
INFO: Elapsed time: 4.650s, Critical Path: 3.09s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
/bin/bash: C:/users/xxxxxxx/_bazel_xxxxxxx/445idx3f/execroot/com_returnpath_xxxxxxxx/bazel-out/x64_windows-fastbuild/bin/gazelle.bash: No such file or directory
PS C:\Users\xxxxxxx\workspace\go\src\github.com\ReturnPath\xxxxxxxx>

I see the gazelle.bash.in file exists, but I don't see how you all solved it.

Edit: I also see that gazelle.bash also exists, not sure why it says it doesn't, or that bash can't find it:

PS C:\Users\xxxxxxx\workspace\go\src\github.com\ReturnPath\xxxxxxxx> dir C:/users/xxxxxxx/_bazel_xxxxxxx/445idx3f/execroot/com_returnpath_xxxxxxxx/bazel-out/x64_windows-fastbuild/bin/

    Directory: C:\users\xxxxxxx\_bazel_xxxxxxx\445idx3f\execroot\com_returnpath_xxxxxxxx\bazel-out\x64_windows-fastbuild\bin

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         1/7/2019   3:56 PM                gazelle.bash.runfiles
-ar---         1/7/2019   3:56 PM           3312 gazelle.bash
-ar---         1/7/2019   3:56 PM            955 gazelle.bash.runfiles_manifest

Edit2: If I run bazel from MSYS instead of from Powershell, (after the bazel server was started from Powershell), I get the following error instead:

xxxxxxx@rpco-cdunca1812 MSYS /c/Users/xxxxxxx/workspace/go/src/github.com/ReturnPath/xxxxxxxx
$ bazel run //:gazelle
WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:
c:\users\xxxxxxx\workspace\go\src\github.com\returnpath\xxxxxxxx/.bazelrc
INFO: Invocation ID: 7ec6de6d-0b99-4411-9b40-923157d9f3be
Loading:
Loading: 0 packages loaded
DEBUG: C:/users/xxxxxxx/_bazel_xxxxxxx/445idx3f/external/bazel_skylib/lib.bzl:30:1: WARNING: lib.bzl is deprecated and will go away in the future, please directly load the bzl file(s) of the module(s) needed as it is more efficient.
Analyzing: target //:gazelle (0 packages loaded, 0 targets configured)
INFO: Analysed target //:gazelle (1 packages loaded, 2 targets configured).
INFO: Found 1 target...
[42 / 43] [-----] BazelWorkspaceStatusAction stable-status.txt
[42 / 43] [-----] BazelWorkspaceStatusAction stable-status.txt
Target //:gazelle up-to-date:
  C:/users/xxxxxxx/_bazel_xxxxxxx/445idx3f/execroot/com_returnpath_xxxxxxxx/bazel-out/x64_windows-fastbuild/bin/gazelle.bash
INFO: Elapsed time: 4.671s, Critical Path: 2.99s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Running command line: C:/users/xxxxxxx/_bazel_xxxxxxx/445idx3f/execroot/com_returnpath_xxxxxxxx/bazel-out/x64_windows-fastbuild/bin/gazelle.bash -bazel_run
INFO: Build completed successfully, 1 total action
C:/users/xxxxxxx/_bazel_xxxxxxx/445idx3f/execroot/com_returnpath_xxxxxxxx/bazel-out/x64_windows-fastbuild/bin/gazelle.bash: line 80: cd: external/go_sdk/bin/..: No such file or directory

Line 80 is:

  # If the script was invoked by "bazel run", jump out of the execroot, into
  # the workspace before running Gazelle.
  # TODO(jayconrod): detect when a command can't be run this way.
  export GOROOT=$(cd "$(dirname "$GOTOOL")/.."; pwd)

[jayconrod]

@veqryn Could you open a new issue? This one's covered a lot of ground already.

Some things to try first though:

• Does it work with cmd? We don't test through PowerShell or MSYS, and I can't make promises there.
• Do you have BAZEL_SH set to MSYS, and PATH set to the bin directory?
• Are you able to bazel run other sh_binary rules?
• Is your working directory very long? Most Windows errors with this message are related to long paths.

[veqryn]

ok: #416