Hacker News Reader

Comment by elteto | Hacker News Reader

It delivers on its premise of always correct, incremental builds but it is extremely opinionated. I don’t blame it for that, maybe having truly hermetic and reproducible builds requires that level of structure. It is almost magical changing a linker flag in some bazel config and see it _only_ relink affected targets.

If you need to do cross-compilation then I feel like it is extremely overengineered with the whole platform/toolchain concepts, and after _years_ the docs are still incredibly lacking on this aspect. I almost prefer the previous approach with the semi-documented protobuf as JSON crosstool file.

If you need the safety guarantees or the reproducibility there’s no other build system out there. If you don’t then you will be inclined to hate it because you are not extracting value of it.

View on HN

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...

Have you come across https://github.com/aspect-build/gcc-toolchain? I use it as a starting point for my toolchains.

Woah I hadn't. Looks super useful, thanks!

My normal workflow to bootstrap cross-compilation with bazel is to create a dummy project with some dummy C/C++ file and build it. Then go into whatever bazel-X internal folder and extract the autogenerated bzl for the local system’s compiler. Then update it with my toolchain and strip it down (I hate the “features” feature) until it is somewhat understandable.

This is a _terrible_ DX.

Yeah, that's the same way I do it.

> It is almost magical changing a linker flag in some bazel config and see it _only_ relink affected targets.

I think this should be expected from any modern build system. Now, if you make a whitespace change in your source file and the build system recognized this and skips recompiling it, that could pass for magic (build2 does this for C/C++ sources).

If the output .o is identical then I think bazel will also skip recompilation, FWIW.

You probably mean relinking: to compare old .o to new, you would need to recompile the source file to get the new .o.

Yes, that's what I meant.

Reply on news.ycombinator.com