From: "brian m. carlson" <sandals@crustytoothpaste•net>
To: Son Luong Ngoc <sluongng@gmail•com>
Cc: git <git@vger•kernel.org>
Subject: Re: contrib/bazel interest check
Date: Mon, 5 Jan 2026 22:43:35 +0000 [thread overview]
Message-ID: <aVw-l-vi4PegDhY3@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <CAL3xRKfeij_3OUzVPv6Mr4bXjwkB_m7DZt6cbisL-VD473QLpQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]
On 2026-01-05 at 15:34:45, Son Luong Ngoc wrote:
> Hi folks,
>
> For my personal use case, I have bootstrapped building libgit and git
> using Bazel, an open-sourced build tool by Google (1). Currently, the
> code is squashed into a giant commit (2) in my repo at
> github.com/sluongng/git in the branch sluongng/next-bazel. The commit
> is based on the 'next' branch from upstream.
>
> Similar to Meson, Bazel requires fine-grained BUILD files to be
> sprinkled throughout the repo. So it's fairly invasive to try to get
> this merged.
>
> I also won't have the capacity to maintain this setup for every new
> upstream topic that comes up. Though I am willing to spend the effort
> to maintain it for major releases.
>
> I want to send this as an interest check to see if there are folks who
> are willing to co-maintain this with me in-tree style inside git.git.
> Otherwise, I plan to send this to the Bazel Central Registry (3), the
> public package registry for the Bazel ecosystem, in overlay mode. The
> overlay shall be applied on top of the checkout copy before Bazel
> starts the build.
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.
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.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2026-01-05 22:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 15:34 contrib/bazel interest check Son Luong Ngoc
2026-01-05 22:43 ` brian m. carlson [this message]
2026-01-06 14:39 ` Son Luong Ngoc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aVw-l-vi4PegDhY3@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=sluongng@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox