Re: contrib/bazel interest check

Hi Brian,

Thanks for giving it a read.

On Mon, Jan 5, 2026 at 11:43 PM brian m. carlson
[off-list ref] wrote:

We already have two officially supported build systems (Make and Meson),
plus CMake in contrib.  I don't think adding a fourth build system would
be a good idea, especially since it's already burdensome enough to deal
with the main two.

Fair take.

There are a few folks who mentioned that they might be interested in this
on the community Discord. Unless those folks are willing to share the
maintenance load, I will go with the out-of-tree approach instead.

I'd also like to encourage you not to send this as-is to the Bazel
Central Registry, since it hard-codes various values that are intended
to be configurable, such as `SHELL_PATH`[0], `PERL_PATH`, and
`PYTHON_PATH`.  It also hard-codes a variety of define values which are
not necessarily correct for all systems (for instance, my Debian
unstable system _does_ have `strlcpy`).  Shipping a build system like
this would be a regression in functionality and result in broken
packages on a variety of systems[1].  If you're suggesting to the public
that this is an appropriate way to build Git in general, it would be
nice if it were no less functional and flexible than our existing build
system.

[0] For instance, I set `SHELL_PATH` to test building and running Git
against zsh from time to time.
[1] As an example, this would not work correctly on the version of Git
a previous employer ships because they ship their own version of Perl
and Python that should be used instead of the system one.

Yeah, the commit is definitely more tailored toward my use case right now
(building libgit and linking it to some Go binaries).

In the Bazel ecosystem, these tool paths are determined by "toolchains"
and the "platforms" selecting which toolchains to use (1).
Luckily, shell, python and perl all already have their dedicated Bazel
rules set (2)(3)(4) with toolchain definitions included.
So one should be able to make these configurable in the future through
respective rules toolchains instead of using the hard-coded value in my
build config. Good call out though.

I guess I will make a note that this is an unofficial,
"community-maintained" build setup when sending this to Bazel's
Central Registry. That should help set the expectation of downstream
users and remind folks that contributions are always welcome.

(1): https://bazel.build/extending/platforms
(2): https://github.com/bazelbuild/rules_shell/blob/main/shell/toolchains/sh_toolchain.bzl
(3): https://github.com/bazel-contrib/rules_python/blob/main/python/private/toolchains_repo.bzl
(4): https://github.com/bazel-contrib/rules_perl/blob/main/perl/toolchain.bzl

--
brian m. carlson (they/them)
Toronto, Ontario, CA

Cheers,
Son Luong.