bazel-team team mailing list archive
Mailing list archive
Re: Bazel build issue on RISC-V
On 12/29/20 12:13 AM, Olek Wojnar wrote:
> I obviously can't speak for the upstream Bazel team, or for their corporate
> sponsor, but I can give you my perspective on this. Bazel is a relatively
> new build system and it is still in very heavy development. It makes sense
> to me that the team would focus their initial efforts on popular 64-bit
> architectures (e.g. amd64 and arm64) for which they have sufficient
> in-house expertise.
It's developed by Google. They have the manpower and the resources to do
that. The point is, they're not interested in supporting platforms besides
the ones they are using commercially. I have seen that in plenty of Google's
projects such as Golang, Skia, Kubernetes.
So I'm pretty sure the 32-bit builds won't ever get fixed.
> The beauty of FLOSS is that people with expertise in different
> can help enable Bazel to build, and run, correctly there. That is why
> I specifically reached out to the RISC-V experts here
> instead of just excluding the architecture from the list.
The problem is that Google has a reputation for quickly abandoning projects
when they feel it no longer has any commercial value for them.
So if the community heavily invests into fixing their bugs, they risk ending
up having spent lots of time and energy into something that will be abandoned
> I'm personally very impressed with what Bazel can do even now, and I think
> it has the potential to be very useful in many FLOSS projects, including
> distributions such as Debian. I'm happy that Google chose to Open Source
> the code instead of keeping it as an internal tool. That's a trend I would
> like to see more of.
There are already plenty of very good and usable build systems that have been
widely adopted, work well and are very portable. A build system that doesn't
even work on half of the release architectures is useless in my opinion.
> So, I'm asking you to please help honor the steps that the upstream Bazel
> team has taken to make their software universally available by helping in
> the areas where neither they (nor the Debian packagers) have
Making your in-house tools open source is not exceptional nowadays, companies
like RedHat and SUSE make it all the time.
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@xxxxxxxxxx
`. `' Freie Universitaet Berlin - glaubitz@xxxxxxxxxxxxxxxxxxx
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913