toolchains_llvm VS rules_python

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") BAZEL_TOOLCHAIN_TAG = "0.7.2" BAZEL_TOOLCHAIN_SHA = "f7aa8e59c9d3cafde6edb372d9bd25fb4ee7293ab20b916d867cd0baaa642529" http_archive( name = "com_grail_bazel_toolchain", sha256 = BAZEL_TOOLCHAIN_SHA, strip_prefix = "bazel-toolchain-{tag}".format(tag = BAZEL_TOOLCHAIN_TAG), canonical_id = BAZEL_TOOLCHAIN_TAG, url = "https://github.com/grailbio/bazel-toolchain/archive/{tag}.tar.gz".format(tag = BAZEL_TOOLCHAIN_TAG), ) load("@com_grail_bazel_toolchain//toolchain:deps.bzl", "bazel_toolchain_dependencies") bazel_toolchain_dependencies() load("@com_grail_bazel_toolchain//toolchain:rules.bzl", "llvm_toolchain") llvm_toolchain( name = "llvm_toolchain", llvm_version = "15.0.5", ) load("@llvm_toolchain//:toolchains.bzl", "llvm_register_toolchains") llvm_register_toolchains() http_archive( name = "com_google_googletest", urls = ["https://github.com/google/googletest/archive/609281088cfefc76f9d0ce82e1ff6c30cc3591e5.zip"], strip_prefix = "googletest-609281088cfefc76f9d0ce82e1ff6c30cc3591e5", )

Yeah the cross-compilation thing is definitely a rough spot. I have one project that's able to work around it via extensive hacks with macros, but at some point I'll need to do it "the right way."

Honestly if the docs had a canonical example of e.g. using unix_cc_toolchain_config (example: [0]) + Bootlin to compile for aarch64, it'd probably go a long way to making things understandable. Because say what you will about the old CROSSTOOL approach, at least there was a nice tutorial for it.

[0] https://github.com/grailbio/bazel-toolchain/blob/f14a8a5de8f...

I'm really not familiar with this issue or Go nor C++ overall, but if all you need is to set up a C++ toolchain, this should be quite simple and solve your issue.

The trick is that to provide Bazel with a custom toolchain involves way more than just setting an environment variable, because Bazel wants to control installing and making available the compiler reliably (e.g., what if `emcc` is not present on the system where Bazel was invoked? Bazel solves that problem by fetching it and building it for that system)

There are projects that provide drop-in support for custom toolchains (e.g., we use this project[0] in Sorbet to fetch and build a custom LLVM/Clang toolchain for every host we build on (rather than relying on the system toolchain). But I'm not aware of a project that has done that for Emscripten. Maybe it would be as easy as plucking out what we've done in our project into a project that others could depend on, but to quote a colleague:

> Setting up a cc toolchain in Bazel is a unique sort of pain.

[0] https://github.com/grailbio/bazel-toolchain/

What's SV?

I honestly don't know why anyone would use that... as in what does Bazel do better than virtually anything else that can provide this functionality. But, I used to be an ops engineer in a big company which wanted everything to be Maven, regardless of whether it does it well or not. So we built and deployed with Maven a lot of weird and unrelated stuff.

Not impossible, but not anything I'd advise anyone to do on their free time.

Specifically wrt' the link you posted, if you look here: https://github.com/bazelbuild/rules_python/blob/main/python/... it says that only pure Python wheels are supported, but that's also a lie, they don't support half of the functionality of pure Python wheels.

So, definitely not worth using, since lots of functionality is simply not there.

Regarding bazel, the rules_python has a py_wheel rule that helps you creating wheels that you can upload to pypi (https://github.com/bazelbuild/rules_python/blob/52e14b78307a...).

If you want to see an approach of bazel to pypi taken a bit to the extreme you can have a look at tensorflow on GitHub to see how they do it. They don't use the above-mentioned building rule because I think their build step is quite complicated (C/C++ stuff, Vida/ROCm support, python bindings, and multiOS support all in one before you can publish to pypi).

Python support in Bazel now looks more promising with `rules_python`: https://github.com/bazelbuild/rules_python

`rules_go` to my understanding is great too.

Over years, Bazel is not as opinionated as before, mostly because adoptions in different orgs force it to be so.

I have personally run converted build systems to Bazel, and use it for personal projects as well.

Bazel 1.0 was released in October 2019. If you were using it "a few years ago", I'm guessing you were using a pre-1.0 version. There's not some cutoff where Bazel magically got easy to use, and I still wouldn't describe it as "easy", but the problem it solves is hard to solve well, and the community support for Bazel has gotten a lot better over the past years.

https://github.com/bazelbuild/rules_python

The difficulty and complexity of using Bazel is highly variable. I've seen some projects where using Bazel is just super simple and easy, and some projects where using Bazel required a massive effort (custom toolchains and the like).

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") #------------------------------------------------------------------------------ # Python #------------------------------------------------------------------------------ # enable python rules http_archive( name = "rules_python", url = "https://github.com/bazelbuild/rules_python/releases/download/0.2.0/rules_python-0.2.0.tar.gz", sha256 = "778197e26c5fbeb07ac2a2c5ae405b30f6cb7ad1f5510ea6fdac03bded96cc6f", )