search

bazelbuild / bazel-gazelle

Gazelle is a Bazel build file generator for Bazel projects. It natively supports Go and protobuf, and it may be extended to support new languages and custom rule sets.
Apache License 2.0
1.15k stars 369 forks source link

Can't run Gazelle in a MinGW environment #562

Open Xjs opened 5 years ago

Xjs commented 5 years ago

I don't know when this started, because I only recently started running gazelle via bazel run, but:

On Windows, I get the following error when trying to run Gazelle:

jannis.schnitzer@jannis-desktop rules-go-modules-error $ bazel run ///:gazelle # three slashes because MINGW mangles args containing slashes
$TEST_TMPDIR defined: output root default is 'c:\tmp' and max_idle_secs default is '15'.
Starting local Bazel server and connecting to it...
(15:53:33) INFO: Current date is 2019-06-27
(15:53:36) INFO: SHA256 (https://github.com/bazelbuild/bazel-gazelle/archive/72ba271916ca02aaaff72949dc0c0a63ab37d395.zip) = 24daaf46f236689229052d3c7e62ce8dbafb26fd4c9bd08429dd8c2a024c20ed
(15:53:38) DEBUG: Rule 'bazel_gazelle' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "24daaf46f236689229052d3c7e62ce8dbafb26fd4c9bd08429dd8c2a024c20ed"
(15:53:38) DEBUG: Call stack for the definition of repository 'bazel_gazelle' which is a http_archive (rule definition at C:/tmp/_bazel_jannis.schnitzer/r67erewf/external/bazel_tools/tools/build_defs/repo/http.bzl:237:16):
 - C:/users/jannis.schnitzer/src/github.com/xjs/rules-go-modules-error/WORKSPACE:12:1
(15:53:47) INFO: Analyzed target //:gazelle (61 packages loaded, 6719 targets configured).
(15:53:47) INFO: Found 1 target...
(15:53:47) INFO: Deleting stale sandbox base C:/tmp/_bazel_jannis.schnitzer/r67erewf/sandbox
Target //:gazelle up-to-date:
  bazel-bin/gazelle-runner.bash
  bazel-bin/gazelle
  bazel-bin/gazelle.exe
(15:53:48) INFO: Elapsed time: 17.688s, Critical Path: 0.82s
(15:53:48) INFO: 0 processes.
(15:53:48) INFO: Build completed successfully, 1 total action
(15:53:48) INFO: Build completed successfully, 1 total action
/bin/bash: C:\tmp\_bazel_jannis.schnitzer\r67erewf\execroot\ag_edg_gogs_priips_ateam_murdock_proxy\bazel-out\x64_windows-fastbuild\bin\gazelle: command not found

I tried with various Gazelle versions (as you can see, this is the lastest commit from master) and with Bazel 0.26.2 and 0.27.0. Maybe the issue has to do with MinGW bash's path mangling, because the referenced file C:\tmp\_bazel_jannis.schnitzer\r67erewf\execroot\ag_edg_gogs_priips_ateam_murdock_proxy\bazel-out\x64_windows-fastbuild\bin\gazelle does exist. It can, however, not be executed by entering its backslashy path into a MinGW bash, only with forward slashes it does work.

So far, I failed trying to trace where exactly that exact file is actually executed. Maybe this is a bazel bug as well.

Xjs commented 5 years ago

When I tried manually executing C:\tmp\_bazel_jannis.schnitzer\r67erewf\execroot\ag_edg_gogs_priips_ateam_murdock_proxy\bazel-out\x64_windows-fastbuild\bin\gazelle, I encountered another problem: https://github.com/bazelbuild/bazel-gazelle/blob/c0880f7f9d7048b45be5d36115ec2bf444e723c4/internal/gazelle.bash.in#L50 strips file:// from the path reported in the build event log, but on Windows, the path will begin with file:///, e. g. "uri":"file:///C:/tmp/_bazel_jannis.schnitzer/r67erewf/execroot/com_github_Xjs_rules_go_module_error/bazel-out/x64_windows-fastbuild/bin/external/bazel_gazelle/cmd/gazelle/windows_amd64_stripped/gazelle.exe". This should be an easy fix though, once the first problem is resolved.

jayconrod commented 5 years ago

@Xjs could you try running through the regular cmd shell? I remember trying MinGW bash in the past, but the path rewriting causes so many problems, I can't really supported.

The second problem seems like a bigger issue though.

Xjs commented 5 years ago

@jayconrod I hadn't thought of that. Works in Powershell.

I'd still be happy to make this work in MinGW bash, because many users in our organisation just use the bash that comes with Git for Windows, but I absolutely understand your point.

(For some reason, Gazelle is successfully executed when running from PowerShell, even though the contents of the build event log are the same as before.)

jayconrod commented 5 years ago

Ideally, this wrapper script should be rewritten in Go so we don't have a bash dependency. I think at the time this was written, we didn't support Windows, but at this point, this is almost the only thing in rules_go and Gazelle that still requires bash.