In [this post](https://discuss.tvm.apache.org/t/add-support-to-bazel/14555), 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 i[ncreasingly mature upstream LLVM overlay](https://github.com/llvm/llvm-project/tree/main/utils/bazel).
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: - [PR on my TVM fork](https://github.com/Wheest/incubator-tvm/pull/12) that adds an initial overlay. - A [consumer bazel project](https://github.com/Wheest/tvm-bazel-consumer) that integrates the overlay, and builds and tests integration 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. --- [Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-bazel-overlay/18976/1) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/c3c80176bef56a96ccbacdabd4f64b964bbf5eba4cb63c600413e3e15d3de0ad).
