4 ms·

I've done this for long enough to not have that confidence. It's not just whether the build system is correct, but also all the external things you do with it,

I've done this for long enough to not have that confidence. It's not just whether the build system is correct, but also all the external things you do with it, random files laying around that aren't referenced by the build system but make it into the release bundle and mess up things at runtime, moon phase, whatnot. Even if Bazel is the ultimate, final, perfect build system, I don't trust everyone, including myself, to use it properly.

klodolph 6y ago
I’ve used Bazel for long enough that I’ve regained that confidence. I don’t think it’s some “ultimate, final, perfect build system”, but it is a build system that doesn't have insidious failure modes when used improperly. Execution of build rules is sandboxed by default so you generally don’t run into the problem of implicit dependencies screwing up your builds—not that you can’t, but you generally don’t.
- iforgotpassword 6y ago
  If I were running a one man show I might actually try, but debugging build problems when you're not the (only) author of the Makefile (equivalent) just isn't fun.
  - klodolph 6y ago
    I feel the opposite way. The larger the team is, the more likely I am to want to switch to Bazel (or something in its class).
- jeffbee 6y ago
  You have to go far out of your way to make bazel not have implicit system deps, don't you? The default toolchain is to just call whatever cc is in the path, or whatever is in CC environment variable. Working on the toolchain rules / crosstool is very little practiced art and severely under-documented.
  - joshuamorton 6y ago
    Yes, see the "host mode".
  - klodolph 6y ago
    It is underdocumented, but you don’t have to go out of your way because you in most cases you can use prepackaged toolchains that other people have made. I have successfully written my own toolchain rules in Bazel. Yes, it is a pain. But it’s usually only necessary if you have some kind of unusual target—usually, someone else has written the toolchain rules for you. I've even witnessed a Bazel build system that made working DOS binaries. The entire set of rules was smaller than you might think.

klodolph 6y ago

I’ve used Bazel for long enough that I’ve regained that confidence. I don’t think it’s some “ultimate, final, perfect build system”, but it is a build system that doesn't have insidious failure modes when used improperly. Execution of build rules is sandboxed by default so you generally don’t run into the problem of implicit dependencies screwing up your builds—not that you can’t, but you generally don’t.

iforgotpassword 6y ago
If I were running a one man show I might actually try, but debugging build problems when you're not the (only) author of the Makefile (equivalent) just isn't fun.
- klodolph 6y ago
  I feel the opposite way. The larger the team is, the more likely I am to want to switch to Bazel (or something in its class).
jeffbee 6y ago
You have to go far out of your way to make bazel not have implicit system deps, don't you? The default toolchain is to just call whatever cc is in the path, or whatever is in CC environment variable. Working on the toolchain rules / crosstool is very little practiced art and severely under-documented.
- joshuamorton 6y ago
  Yes, see the "host mode".
- klodolph 6y ago
  It is underdocumented, but you don’t have to go out of your way because you in most cases you can use prepackaged toolchains that other people have made. I have successfully written my own toolchain rules in Bazel. Yes, it is a pain. But it’s usually only necessary if you have some kind of unusual target—usually, someone else has written the toolchain rules for you. I've even witnessed a Bazel build system that made working DOS binaries. The entire set of rules was smaller than you might think.