4 ms·

How does this solve the build time problem the parent post was lamenting? I’ve looked a little bit at bazel but haven’t spent long on it. It seems to really, r

How does this solve the build time problem the parent post was lamenting? I’ve looked a little bit at bazel but haven’t spent long on it. It seems to really, really want you to do things in its specific googly way ( that seems to stem from monorepo style and always knowing the exact build path and never needing to distribute to users) which is hard if e.g. trying to to convert an existing project that doesn’t perfectly fit (us: combined C++/Python with some legacy fortran generation) Or a project that has external dependencies currently being chain-built but isn’t itself built with bazel (e.g. most the planet) - we don’t all have dedicated build teams to accurately and bug free reproduce other libraries build procedure (also getting away from a buggy reproduced build is part of my system rewrite intention). I seem to remember the documentation also had the usual problem that the easy examples were well documented but hard to tell how to do anything more complex, but maybe I didn’t dig enough. CMake has a similarish problem except the problem is finding more modern ways of doing things that don’t suck (I’m aware of all the talks about this, many of them are big on ambition but low on details, and usually just teach transient dependencies).

misnome 8y ago
Ignore the first sentence, I think I misread what you were specifically commenting on for that.
jchw 8y ago
It improves the build time problem by offering a way to do fast, hermetic builds. Caching is very accurate, targets only rebuild exactly when they need to, and you can distribute just about any kind of work over a build farm. It may not sound like much, but having the distribution at the build system level, versus say, distcc, makes a big difference, especially if you have long build steps that aren't just compilation. You literally can't accidentally have dependencies that aren't explicitly defined. When you go to compile it will not find headers from targets that are not depended on, for example. >I’ve looked a little bit at bazel but haven’t spent long on it. It seems to really, really want you to do things in its specific googly way ( that seems to stem from monorepo style and always knowing the exact build path and never needing to distribute to users) which is hard if e.g. trying to to convert an existing project that doesn’t perfectly fit (us: combined C++/Python with some legacy fortran generation) I don't really think this is the case. There's definitely certain aspects that can be challenging but I do not feel it has much to do with monorepos. It works well with a monorepo using the workspaces system, but it also should work fairly well using modular git repos as well, each repo is just treated as it's own workspace. It's possible to even have Bazel go and get other workspaces, and you can refer to targets inside of other workspaces. One of my favorite parts about Bazel is combining different languages. If Starlark rules for the language you are trying to build for don't exist, you can write them. Starlark is a fair bit like Python, it's relatively easy to learn and write your own targets. I acknowledge that most people don't want to maintain BUILD files for external stuff. There are some options here. Some people already maintain this, like here: https://github.com/bazelregistry https://github.com/bazelregistry - and there are experimental rules for dealing with external build systems. I use it outside of Google on personal projects and find it perfectly manageable. You don't really need a large build team unless you're doing interesting things. There are a few aspects of Bazel that really are tough, like how you must explicitly specify dependencies on every target, and how actual builds can't even see files not specified in dependencies, and when you get fairly deep you'll probably run into trying to understand what's going on with runfiles. It's definitely a bit more compliant than a Makefile generator at this point. But in exchange, it delivers on its promise of being fast and correct.

misnome 8y ago

Ignore the first sentence, I think I misread what you were specifically commenting on for that.

jchw 8y ago

It improves the build time problem by offering a way to do fast, hermetic builds. Caching is very accurate, targets only rebuild exactly when they need to, and you can distribute just about any kind of work over a build farm. It may not sound like much, but having the distribution at the build system level, versus say, distcc, makes a big difference, especially if you have long build steps that aren't just compilation. You literally can't accidentally have dependencies that aren't explicitly defined. When you go to compile it will not find headers from targets that are not depended on, for example. >I’ve looked a little bit at bazel but haven’t spent long on it. It seems to really, really want you to do things in its specific googly way ( that seems to stem from monorepo style and always knowing the exact build path and never needing to distribute to users) which is hard if e.g. trying to to convert an existing project that doesn’t perfectly fit (us: combined C++/Python with some legacy fortran generation) I don't really think this is the case. There's definitely certain aspects that can be challenging but I do not feel it has much to do with monorepos. It works well with a monorepo using the workspaces system, but it also should work fairly well using modular git repos as well, each repo is just treated as it's own workspace. It's possible to even have Bazel go and get other workspaces, and you can refer to targets inside of other workspaces. One of my favorite parts about Bazel is combining different languages. If Starlark rules for the language you are trying to build for don't exist, you can write them. Starlark is a fair bit like Python, it's relatively easy to learn and write your own targets. I acknowledge that most people don't want to maintain BUILD files for external stuff. There are some options here. Some people already maintain this, like here: https://github.com/bazelregistry https://github.com/bazelregistry - and there are experimental rules for dealing with external build systems. I use it outside of Google on personal projects and find it perfectly manageable. You don't really need a large build team unless you're doing interesting things. There are a few aspects of Bazel that really are tough, like how you must explicitly specify dependencies on every target, and how actual builds can't even see files not specified in dependencies, and when you get fairly deep you'll probably run into trying to understand what's going on with runfiles. It's definitely a bit more compliant than a Makefile generator at this point. But in exchange, it delivers on its promise of being fast and correct.