Improve Windows support and make the top-level buildozer target public

[sputt]

We should support

alias(
    name = "buildozer",
    actual = "@buildozer//:buildozer",
    tags = ["manual"],
)

I think this makes more sense than bringing buildozer_binary into scope in my module

[fmeum]

Thanks for the suggestion!

I so far haven't exposed this target publicly since referencing it with anything that isn't alias (say another sh_binary) doesn't work as the env attribute wouldn't apply.

We could fix this by hardcoding the rlocationpath in

buildozer/buildozer.sh

Line 23 in 7871d11

buildozer_path=$(rlocation $BUILDOZER_RLOCATIONPATH)

. Would you be interested in giving that a try?

[sputt]

Thanks for the suggestion!

I so far haven't exposed this target publicly since referencing it with anything that isn't alias (say another sh_binary) doesn't work as the env attribute wouldn't apply.

We could fix this by hardcoding the rlocationpath in

buildozer/buildozer.sh

Line 23 in 7871d11

buildozer_path=$(rlocation $BUILDOZER_RLOCATIONPATH)

. Would you be interested in giving that a try?

Ah yes right you are. If we going to render we can also support Windows. I'll render the shell script and batch script when I get back to a Windows PC.

[sputt]

@fmeum should be good to go

[fmeum]

Instead of injecting this variable, we should be able to just use buildozer_binary/buildozer (plus the OS-dependent extension). That avoids having to stamp in the path, which in turn allows us to avoid the .bat script. It looks pretty good (thanks for giving me an idea of what that would look like!), but I'm not sure that it fully follows the runfiles discovery process - for example, what if someone builds with runfiles enabled on Windows?

[sputt]

Having an inner repo for the binary requires a rendered script. As far as I know, there is no other way to locate the binary when runfiles are disabled - which is the default state of a Windows box.

When running in command prompt, batch is also required. Here is a stock windows box with bazelisk only:

C:\Users\clzdg\Projects\buildozer>bazel run @buildozer -- -h
WARNING: Build option --enable_runfiles has changed, discarding analysis cache (this can be expensive, see https://bazel.build/advanced/performance/iteration-speed).
INFO: Analyzed target //:buildozer (1 packages loaded, 7 targets configured).
INFO: Found 1 target...
Target @@+buildozer_binary+buildozer_binary//:source_buildozer up-to-date:
  bazel-bin/external/+buildozer_binary+buildozer_binary/source_buildozer.sh
INFO: Elapsed time: 0.618s, Critical Path: 0.02s
INFO: 5 processes: 5 internal.
INFO: Build completed successfully, 5 total actions
INFO: Running command line: bazel-bin/external/+buildozer_binary+buildozer_binary/source_buildozer.sh <args omitted>
FATAL: ExecuteProgram(C:\users\clzdg\_bazel_clzdg\2qmadfcc\execroot\_main\bazel-out\x64_windows-fastbuild\bin\external\+buildozer_binary+buildozer_binary\source_buildozer.sh) failed: ERROR: src/main/native/windows/process.cc(202): CreateProcessW("C:\users\clzdg\_bazel_clzdg\2qmadfcc\execroot\_main\bazel-out\x64_windows-fastbuild\bin\external\+buildozer_binary+buildozer_binary\source_buildozer.sh"  -h): %1 is not a valid Win32 application.
 (error: 193)

I updated the batch file to be a bit smarter. This is generally modeled after https://github.com/bazelbuild/bazel-skylib/blob/main/rules/diff_test.bzl, but unfortunately the test wrapper provides the runfiles envvars that make their runfiles discovery simpler, so we have a sillier MANIFEST direct lookup.

I think we need a batch runfiles library, only 10k lines of batch and you've got a repo mapping baby.

[fmeum]

The batch script looks pretty accurate now, but I think that we can still avoid it. Please take a look at #23, which is based on your PR but hardcodes the rlocationpath with an apparent repository name. It doesn't work on 6.2.0 as the runfiles library had a bug, but it works on 6.x.