3 ms·

Bazel's selling point is that it's designed to be integrated into various pipelines, handling complexity (multiple languages, platforms, targets, etc) AND being

by pas 6y ago

Bazel's selling point is that it's designed to be integrated into various pipelines, handling complexity (multiple languages, platforms, targets, etc) AND being fast (cache what you can, so incremental builds are first class things). Of course under the hood it's just a very complicated 'make', like every build tool is. This likely just means unnecessary complexity for a simple Java project where the development just happens in IDEA (or Eclipse or even NetBeans) and the IDE builds and checks everything, and ... at release time someone just builds a package and it's done. But in case of a project with a lot of services, dependencies, there's arguably some advantage to setting up Bazel to help with development. (Though the build/bzl files all look ugly and unintuitive, a bit like CMake :[ )

skinkestek 6y ago
Does it encourage every team and every dev to create their own custom config that takes two hours to figure out like Gradle, or is it more like Maven where you only specify anything that isn't bog standard?
- foota 6y ago
  It's very standardized. I don't have any experience with using it with things outside a Java binary, but for that use case you basically have no choice but a number of java_library rules and a java_binary. E.g., a simple project with no outside deps might be like (and I typed this out on my phone): java_binary(name = "grep_bin", srcs = ["grep_main.java"], deps=["grep_lib"]) java_library(name="grep_lib", srcs =["grep_lib.java"]) Things get more opinionated when you pull in outside libraries, but even then bazel makes it fairly painless and integrates with other build systems where needed. Take a look at the docs here for more info: https://docs.bazel.build/versions/master/be/java.html https://docs.bazel.build/versions/master/be/java.html
- pas 6y ago
  It has support for many languages (called rules [0]) and it has support for many tools for that specific language ecosystem. For example the Scala rules have specs2 (a unit testing lib/harness/framework/thing) [1] I have no idea how this all works in practice. [0] https://github.com/bazelbuild/bazel/blob/master/site/docs/rules.md#rules https://github.com/bazelbuild/bazel/blob/master/site/docs/ru... [1] https://github.com/bazelbuild/rules_scala/blob/master/examples/testing/specs2_junit_repositories/example/BUILD https://github.com/bazelbuild/rules_scala/blob/master/exampl...
- izacus 6y ago
  No, it's actually the opposite - it has very rigid build rules with rigid inputs and outputs so the toolchain can reason about dependencies and it doesn't really allow adding arbitrary execution in the BUILD files to prevent code messing up caching and remote builds. It was build to solve a problem of building software at scale across multiple languages, platforms in a single monorepo. And it's great at that. It becomes limiting as your use-case steps away from this "monorepo, across languages" approach.

by pas 6y ago

skinkestek 6y ago

Does it encourage every team and every dev to create their own custom config that takes two hours to figure out like Gradle, or is it more like Maven where you only specify anything that isn't bog standard?

foota 6y ago
It's very standardized. I don't have any experience with using it with things outside a Java binary, but for that use case you basically have no choice but a number of java_library rules and a java_binary. E.g., a simple project with no outside deps might be like (and I typed this out on my phone): java_binary(name = "grep_bin", srcs = ["grep_main.java"], deps=["grep_lib"]) java_library(name="grep_lib", srcs =["grep_lib.java"]) Things get more opinionated when you pull in outside libraries, but even then bazel makes it fairly painless and integrates with other build systems where needed. Take a look at the docs here for more info: https://docs.bazel.build/versions/master/be/java.html https://docs.bazel.build/versions/master/be/java.html
pas 6y ago
It has support for many languages (called rules [0]) and it has support for many tools for that specific language ecosystem. For example the Scala rules have specs2 (a unit testing lib/harness/framework/thing) [1] I have no idea how this all works in practice. [0] https://github.com/bazelbuild/bazel/blob/master/site/docs/rules.md#rules https://github.com/bazelbuild/bazel/blob/master/site/docs/ru... [1] https://github.com/bazelbuild/rules_scala/blob/master/examples/testing/specs2_junit_repositories/example/BUILD https://github.com/bazelbuild/rules_scala/blob/master/exampl...
izacus 6y ago
No, it's actually the opposite - it has very rigid build rules with rigid inputs and outputs so the toolchain can reason about dependencies and it doesn't really allow adding arbitrary execution in the BUILD files to prevent code messing up caching and remote builds. It was build to solve a problem of building software at scale across multiple languages, platforms in a single monorepo. And it's great at that. It becomes limiting as your use-case steps away from this "monorepo, across languages" approach.