{"thread":{"id":"64727","subject":"contrib/bazel interest check","startedAt":"2026-01-05T15:34:58Z","lastAt":"2026-01-06T14:39:23Z","messageCount":3,"participants":["Son Luong Ngoc","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"533061","messageId":"CAL3xRKfeij_3OUzVPv6Mr4bXjwkB_m7DZt6cbisL-VD473QLpQ@mail.gmail.com","threadId":"64727","inReplyTo":null,"subject":"contrib/bazel interest check","fromName":"Son Luong Ngoc","fromEmail":"sluongng@gmail.com","sentAt":"2026-01-05T15:34:45Z","receivedAt":"2026-01-05T15:34:58Z","isPatch":false,"sender":{"key":"sluongng@gmail.com","avatar":"https://avatars.githubusercontent.com/u/26684313?v=4"},"body":"  Hi folks,\n\n  For my personal use case, I have bootstrapped building libgit and git\n  using Bazel, an open-sourced build tool by Google (1).  Currently, the\n  code is squashed into a giant commit (2) in my repo at\n  github.com/sluongng/git in the branch sluongng/next-bazel.  The commit\n  is based on the 'next' branch from upstream.\n\n  Similar to Meson, Bazel requires fine-grained BUILD files to be\n  sprinkled throughout the repo.  So it's fairly invasive to try to get\n  this merged.\n\n  I also won't have the capacity to maintain this setup for every new\n  upstream topic that comes up.  Though I am willing to spend the effort\n  to maintain it for major releases.\n\n  I want to send this as an interest check to see if there are folks who\n  are willing to co-maintain this with me in-tree style inside git.git.\n  Otherwise, I plan to send this to the Bazel Central Registry (3), the\n  public package registry for the Bazel ecosystem, in overlay mode.  The\n  overlay shall be applied on top of the checkout copy before Bazel\n  starts the build.\n\n  Although the patch is currently unpolished and only supports Linux, it\n  can already run most of the unit and integration tests under t/ dir to\n  verify libgit and git.  MacOS and Windows support can be added as we\n  mature the setup over time.\n\n  (1): https://github.com/bazelbuild/bazel\n  (2): https://github.com/sluongng/git/commit/04c5a9ec4c3634469b2b7eafd8ba21e09ec3b326\n  (3): https://github.com/bazelbuild/bazel-central-registry\n"},{"id":"533089","messageId":"aVw-l-vi4PegDhY3@fruit.crustytoothpaste.net","threadId":"64727","inReplyTo":"CAL3xRKfeij_3OUzVPv6Mr4bXjwkB_m7DZt6cbisL-VD473QLpQ@mail.gmail.com","subject":"Re: contrib/bazel interest check","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-01-05T22:43:35Z","receivedAt":"2026-01-05T22:43:42Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2026-01-05 at 15:34:45, Son Luong Ngoc wrote:\n>   Hi folks,\n> \n>   For my personal use case, I have bootstrapped building libgit and git\n>   using Bazel, an open-sourced build tool by Google (1).  Currently, the\n>   code is squashed into a giant commit (2) in my repo at\n>   github.com/sluongng/git in the branch sluongng/next-bazel.  The commit\n>   is based on the 'next' branch from upstream.\n> \n>   Similar to Meson, Bazel requires fine-grained BUILD files to be\n>   sprinkled throughout the repo.  So it's fairly invasive to try to get\n>   this merged.\n> \n>   I also won't have the capacity to maintain this setup for every new\n>   upstream topic that comes up.  Though I am willing to spend the effort\n>   to maintain it for major releases.\n> \n>   I want to send this as an interest check to see if there are folks who\n>   are willing to co-maintain this with me in-tree style inside git.git.\n>   Otherwise, I plan to send this to the Bazel Central Registry (3), the\n>   public package registry for the Bazel ecosystem, in overlay mode.  The\n>   overlay shall be applied on top of the checkout copy before Bazel\n>   starts the build.\n\nWe already have two officially supported build systems (Make and Meson),\nplus CMake in contrib.  I don't think adding a fourth build system would\nbe a good idea, especially since it's already burdensome enough to deal\nwith the main two.\n\nI'd also like to encourage you not to send this as-is to the Bazel\nCentral Registry, since it hard-codes various values that are intended\nto be configurable, such as `SHELL_PATH`[0], `PERL_PATH`, and\n`PYTHON_PATH`.  It also hard-codes a variety of define values which are\nnot necessarily correct for all systems (for instance, my Debian\nunstable system _does_ have `strlcpy`).  Shipping a build system like\nthis would be a regression in functionality and result in broken\npackages on a variety of systems[1].  If you're suggesting to the public\nthat this is an appropriate way to build Git in general, it would be\nnice if it were no less functional and flexible than our existing build\nsystem.\n\n[0] For instance, I set `SHELL_PATH` to test building and running Git\nagainst zsh from time to time.\n[1] As an example, this would not work correctly on the version of Git\na previous employer ships because they ship their own version of Perl\nand Python that should be used instead of the system one.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"533146","messageId":"CAL3xRKdmyeSSKKqo529JTeg9ko1swJAwoZCHWT=GzJKZ-MV+Qg@mail.gmail.com","threadId":"64727","inReplyTo":"aVw-l-vi4PegDhY3@fruit.crustytoothpaste.net","subject":"Re: contrib/bazel interest check","fromName":"Son Luong Ngoc","fromEmail":"sluongng@gmail.com","sentAt":"2026-01-06T14:39:11Z","receivedAt":"2026-01-06T14:39:23Z","isPatch":false,"sender":{"key":"sluongng@gmail.com","avatar":"https://avatars.githubusercontent.com/u/26684313?v=4"},"body":"Hi Brian,\n\nThanks for giving it a read.\n\nOn Mon, Jan 5, 2026 at 11:43 PM brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n>\n> We already have two officially supported build systems (Make and Meson),\n> plus CMake in contrib.  I don't think adding a fourth build system would\n> be a good idea, especially since it's already burdensome enough to deal\n> with the main two.\n\nFair take.\n\nThere are a few folks who mentioned that they might be interested in this\non the community Discord. Unless those folks are willing to share the\nmaintenance load, I will go with the out-of-tree approach instead.\n\n> I'd also like to encourage you not to send this as-is to the Bazel\n> Central Registry, since it hard-codes various values that are intended\n> to be configurable, such as `SHELL_PATH`[0], `PERL_PATH`, and\n> `PYTHON_PATH`.  It also hard-codes a variety of define values which are\n> not necessarily correct for all systems (for instance, my Debian\n> unstable system _does_ have `strlcpy`).  Shipping a build system like\n> this would be a regression in functionality and result in broken\n> packages on a variety of systems[1].  If you're suggesting to the public\n> that this is an appropriate way to build Git in general, it would be\n> nice if it were no less functional and flexible than our existing build\n> system.\n>\n> [0] For instance, I set `SHELL_PATH` to test building and running Git\n> against zsh from time to time.\n> [1] As an example, this would not work correctly on the version of Git\n> a previous employer ships because they ship their own version of Perl\n> and Python that should be used instead of the system one.\n\nYeah, the commit is definitely more tailored toward my use case right now\n(building libgit and linking it to some Go binaries).\n\nIn the Bazel ecosystem, these tool paths are determined by \"toolchains\"\nand the \"platforms\" selecting which toolchains to use (1).\nLuckily, shell, python and perl all already have their dedicated Bazel\nrules set (2)(3)(4) with toolchain definitions included.\nSo one should be able to make these configurable in the future through\nrespective rules toolchains instead of using the hard-coded value in my\nbuild config. Good call out though.\n\nI guess I will make a note that this is an unofficial,\n\"community-maintained\" build setup when sending this to Bazel's\nCentral Registry. That should help set the expectation of downstream\nusers and remind folks that contributions are always welcome.\n\n(1): https://bazel.build/extending/platforms\n(2): https://github.com/bazelbuild/rules_shell/blob/main/shell/toolchains/sh_toolchain.bzl\n(3): https://github.com/bazel-contrib/rules_python/blob/main/python/private/toolchains_repo.bzl\n(4): https://github.com/bazel-contrib/rules_perl/blob/main/perl/toolchain.bzl\n\n> --\n> brian m. carlson (they/them)\n> Toronto, Ontario, CA\n\nCheers,\nSon Luong.\n"}]}