3 ms·

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

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.

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.