Add bazel support for coredns?

[yongtang]

This is a discussion about possibly adding bazel support for CoreDNS.

Admittedly, I was not a big fun of bazel in the past for several reasons:

1. Bazel releases in the past break API compatibility almost every 3-4 weeks.

   When working on C++-heavy projects such as tensorflow, were forced to stick with very one version of bazel and there was even no margin of variants for bazel versions.

   For example, at one point tf was forced to stick with bazel 0.24.1 alone, for more than a couple of months. Not even 0.24.0 or 0.25.0. Otherwise, bazel will throw out a huge error message such that you just want to give up.

2. Bazel tries to cover many languages. However, other than C++, bazel was not truly mature or follow other language's common practices. In one of a C++ + python project we stays with pytest for that specific reason.

3. Bazel is probably the best build tool for C++ (I used scons and gyp long time ago). However, There are still some edge cases in C++ bazel didn't cover.

   For example, last time I checked, Bazel's cc_import does not support soname like libmylib.so.2 ([feature request] Support cc_import of .so with soname bazelbuild/bazel#7059).

But there are also some nice features of bazel:

1. Bazel's remote cache is very nice for an organization. That is probably the best feature out of bazel if set correctly.

2. Bazel run everything in a sandboxed environment. That means you really don't need to worry about multiple versions of your compiler. This is especially handy in macOS machines as I don't want to setup those environment variables all over the places for GO_PATH, etc.

3. Bazel is reaching 1.0 so I assume the API compatibility issue will be in much better shape.

4. Language support is catching up so it is becoming a viable tool if the project is multiple-language.

Open this issue for further discussion, to see if we could start thinking about using bazel.

[miekg]

[ Quoting <notifications@github.com> in "[coredns/coredns] Add bazel support..." ]

Open this issue for further discussion, to see if we could start thinking about using bazel.

With gazelle you can just create your WORKSPACE and BUILD.bazel files automatically from the go.mod With a small `alias` definition you don't even have to create a mirror of the github code internally. I don't *really* see why would should carry these files in the repo. Another reason *not* to do it, is to avoid "insert-favorite-other-build-system" discussion, this alludes to . My 2C

[chrisohaver]

What problems are we solving by moving to bazel?

[yongtang]

I don't really see why would should carry these files in the repo

Yes 80+ files is a concern. thanks for the feedback.

[yongtang]

What problems are we solving by moving to bazel?

One background is that I see increasing usage of bazel in container and k8s eco. Many projects offers at least an alternative bazel build solution, mostly for organizations that could take advantage of remote caching.

[yongtang]

Let me close this issue for now. Looks like it does not wide enough need yet.

[miekg]

[ Quoting <notifications@github.com> in "Re: [coredns/coredns] Add bazel sup..." ]

> What problems are we solving by moving to bazel? One background is that I see increasing usage of bazel in container and k8s eco. Many projects offers at least an alternative bazel build solution, mostly for organizations that could take advantage of remote caching.

note that 'apt-get install bazel' is not a thing yet as it's apparently very hard to package as well - as long as that doesn't happen and don't see this growing in the OSS space.