A tangible item for this issue could be to start integrating Bazel into this repository. Eventually, this entire repo will become a Bazel repo.
Why we use bazel?
Things we commonly do with Bazel:
build dependencies / tools in other languages than Go
build other language apps and add them to the Go app (go-bindata)
setup and manage all tools within bazel automatically (Go compiler, protobuf compilers, npm, create-react-app, go-bindata, ...). "bazel build" just works, regardless of the development machine and the version of the tools installed there.
build tar.gz archives, Debian packages and Docker images (you do not need to be using Debian or running Docker to be able to build those things).
in case of Docker, we often build and add "tini" (a small init system written in C) to our "FROM scratch" images.
It's really nice to just write "bazel build //hello-world:debian" for example, and let it figure out how to install and update the Go compiler, build and embed React if necessary, compile the protobuf compilers, generate the protobuf files, compile the Go stuff and generate a Debian package that can be easily installed.
Advantages of Bazel over Make
Advantages over "make" are that dependencies are tracked much better. If you do not have listed a dependency explicitly (e.g. by forgetting to list a .h file in your current directory), then the dependency will not be available. Bazel uses a sandbox / virtual filesystem and only allows access to files listed as dependency. Therefore you do not need to run things like "make clean" ever. You can always build incrementally and your build is always up-to-date and correct. You can even add remote build caches and remote builders if you like.
How to use Bazel
Bazel might look complicated at first, but it really isn't. At least not compared to any of the other build systems... There are predefined rules for nearly everything (e.g. go_package, go_binary, go_proto_library, etc.) that are extremely simple to use. In case of Go, you can use "bazel run //:gazelle" to generate all Bazel build files automatically. You have to copy a WORKSPACE and a BUILD file snippet from the README once in order to make it work, but after that it is as easy to use as "go build".
Hi all,
A tangible item for this issue could be to start integrating Bazel into this repository. Eventually, this entire repo will become a Bazel repo.
Why we use bazel? Things we commonly do with Bazel:
It's really nice to just write "bazel build //hello-world:debian" for example, and let it figure out how to install and update the Go compiler, build and embed React if necessary, compile the protobuf compilers, generate the protobuf files, compile the Go stuff and generate a Debian package that can be easily installed.
Advantages of Bazel over Make Advantages over "make" are that dependencies are tracked much better. If you do not have listed a dependency explicitly (e.g. by forgetting to list a .h file in your current directory), then the dependency will not be available. Bazel uses a sandbox / virtual filesystem and only allows access to files listed as dependency. Therefore you do not need to run things like "make clean" ever. You can always build incrementally and your build is always up-to-date and correct. You can even add remote build caches and remote builders if you like.
How to use Bazel Bazel might look complicated at first, but it really isn't. At least not compared to any of the other build systems... There are predefined rules for nearly everything (e.g. go_package, go_binary, go_proto_library, etc.) that are extremely simple to use. In case of Go, you can use "bazel run //:gazelle" to generate all Bazel build files automatically. You have to copy a WORKSPACE and a BUILD file snippet from the README once in order to make it work, but after that it is as easy to use as "go build".