toolchains_llvm VS Bazel

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/

Wow, if you curl it, there's a lot of boilerplate code there.

Maybe built using Bazel?

https://bazel.build

Bazel by Google

Luckily a feature to limit the disk cache size is in development: https://github.com/bazelbuild/bazel/issues/5139

This is a problem that Bazel (https://bazel.build) solves in a very convenient way. You can just keep using the paths relative to the repository root, and as long as you properly declare your test needs that file it will access it without problems. Or you can use the runfile libraries to access them too.

When doing research for this lab exercise I looked at both vcpkg and conan. Both are package managers that would automate the installation and configuration of my program with its dependencies. However, when it came to releasing and sharing my program my options were limited. For example, the central public registry for conan packages is conan-center, but these packages are curated and the process is very involved. There was no way conan-center would accept a class project like mine. Alternatively, I could host a conan package on a public Artifactory repository, but accessing the package requires users to add the repository to their conan remote. This already sounded like too many steps to expect regular users to follow - I already haven't setup any conan remotes, there's no way I could expect regular users to know about conan remotes, let alone have conan installed on their system. After discussing with people online and consulting my instructor, I ultimately decided to do a GitHub release. However, in the future I was encouraged to look into using CMake or bazel.

NOTE: I won’t mention SBT and Leiningen here because, with all due respect, they are niche build tools. I also won’t discuss Kobalt for the same reason (besides, it’s no longer actively maintained). Additionally, I won’t touch upon Bazel and Buck in this context, mainly because I’m not very familiar with them. If you have insights or comments about these tools, please feel free to share them in the comments 👇

> None of this solves C's only REAL problem (in my opinion) which is the lack of dependency management.

Bazel solves this really nicely, I know some people have strong opinions on it but I cannot recommend it enough

https://bazel.build/