[pre-rfc] bazel overlay

Development RFC
1

In this post, there was a discussion about adding bazel support. This was a few years ago, and since then Bazel is now being used in more projects, and also has an increasingly mature upstream LLVM overlay.

I was looking at adding TVM to a bazel project that I have, and although I was able to get it working, it was very janky and hacky. Therefore, I thought I’d have a look at what would be required to do a LLVM-style overlay in upstream TVM, where we still keep the tried and tested CMake infra, but have an overlay of Bazel targets (outwith the main source tree) that make it easier for folk to integrate TVM with their bazel projects.

I can justify Bazel integration more if needed, but I think it’s better to just get into it. I’ve made the following:

Parts of the Bazel overlay were developed with Claude assistance to rapidly iterate on BUILD file structure, dependency resolution, and configuration patterns. This allowed a quick working proof-of-concept, but for a production-ready contribution I’d rather get more into the weeds with it.

One thing to note as that this approaches lets one use hermetic LLVM, integrated into the Bazel build.

I still need to get the following working;

  • Additional backends (CUDA, Metal, Vulkan)
  • Python bindings support (see note below)

What I’m trying to gauge in this pre-RFC post is if there is interest in the community for Bazel overlay support, or if the maintenance burden versus number of users would not be worth it.

Various things of note

Python Bindings

Python bindings are scaffolded but not fully functional. The challenge:

  1. TVM uses importlib.metadata to locate shared libraries via pip package metadata
  2. Bazel’s hermetic model doesn’t naturally support pip-style package discovery
  3. FFI complexity: The tvm_ffi Python package expects to find libtvm.so via package metadata

Possible solutions (future work):

  • Custom tvm_ffi loader that uses Bazel runfiles
  • Generate synthetic package metadata at build time
  • Hybrid approach where Python tests use a Bazel-built libtvm.so with manual CDLL loading

For now, C++ is the supported interface for Bazel-built TVM.

Git Submodules Solution

TVM uses git submodules for some dependencies (tvm-ffi, dlpack, libbacktrace). The http_archive rule doesn’t fetch submodules. We could use the git_repository, my impression is that http_archive is strongly preferred over git_repository for production builds

Solution: fetch submodules as separate http_archive repos, preserving all http_archive benefits. This does mean that one has quite a few hashes in the consumer to keep track of, but so it goes.