Hacker News Reader

Comment by rjsw | Hacker News Reader

Firefox will currently build on more platforms than Bazel does. Getting fed up of the endless list of new build systems.

View on HN

What platforms are you talking about specifically? Bazel builds for Windows, Linux, MacOS, iOS, Android.

Just guessing: BSDs, ARM (eg Raspberry Pi), PPC, Haiku, Minix

FreeBSD has official Bazel support. ARM and PPC are not platforms, and they run OpenJDK and Bazel just fine.

OpenBSD and NetBSD have OpenJDK ports, but will probably require some patches.

The Haiku OS and Minix Firefox ports appear to be unmaintained.

Note that all of these are unofficial ports - all of Mozilla's supported platforms are also supported by Bazel.

I agree, and inflicting Bazel's horrible Java dependency on Firefox would be a tragedy.

What's wrong with the Java dependency? There's even a single-binary Bazel executable[1] that brings its own embedded OpenJDK. My company is using Bazel and the Java dependency has never been an issue.

Even if you write custom rules, you use the Python-like Skylark language and never interact with Java code.

[1]: https://github.com/bazelbuild/bazel/releases (the single-binary distribution is bazel-1.1.0-linux-x86_64, it's only 40MB).

When using a source based distro or aiming for reproducible builds you'd need to pull in Java to produce Bazel.

And the C compiler springs out of thin air into existence?

No, that's generated also, but is highly reusable whereas some people get along completely fine without Java (unless you make them pull it in for Bazel for Firefox).

So a matter of opinion and language religion.

Well, no. Reproducible builds are a security concern and a source base distro is highly optimizable and configurable. Just because you do not see the purpose does not mean one is absent.

But you can still do reproducible builds with Java. GP refers to wanting to avoid Java for no good reason, not reproducible builds themselves.

Unless you happen to use certified compilers, reproducible builds are a best hope kind of thing.

How is it different than depending on e.g. Python?

Ask any person that has ever tried to package a python and a java package for any linux distribution.

The Python ecosystem is much, much simpler than Java.

Is it, really?

The Java ecosystem had painless build artifacts figured out way before Python did (ship this directory of .jar files vs... a requirements.txt?).

Java's build artifacts are too painless. GNU/Linux distributions tend to have a policy of "we build things from source, we don't simply re-publish the authors' build artifacts." Because Java's build artifacts are so painless, source artifacts and build processes are neglected. I'm convinced that there are many "foundational" Java libraries that have never been successfully compiled on anything but the original author's computer, right before they uploaded the .jar to Maven Central.

With a Java package, the final distro package will mostly be a single .jar file under /usr/share/java/, but getting to that .jar file from source is often a nightmare.

With a Python package, the final distro package will mostly be a sprawling directory under /usr/lib/python/site-packages/, but getting that directory from source is very rarely anything more than `./setup.py install --optimize=1`.

Agreed about Maven Central. It's scary.

In my experience, large, complicated Python packages with C dependencies can be a huge nightmare just like large Java applications, and simple cases are simple in either case. With many dependencies, you need to unbundle every single one and package it separately, in either case.

Here's a simple, random Java package in Fedora:

https://src.fedoraproject.org/rpms/maven-antrun-plugin/blob/...

It only specifies its dependencies (which are individually packaged), and the %mvn_build and %mvn_install macros take care of everything else.

A slightly more complicated one, Guava:

https://src.fedoraproject.org/rpms/guava/blob/master/f/guava...

Elasticsearch, including unbundling patches:

https://src.fedoraproject.org/rpms/elasticsearch/blob/master...

Python doesn't currently require a working Python binary to build itself. Both Bazel and Java do.

A C compiler, which Python needs, is arguably as complex as either a Python or Java runtime.

This is an irrelevant statement. You need the C compiler anyway. Your Java or Python is built with C. You add the complexity of your other environment on top of it.

A C compiler is a functional requirement of any operating system these days.

You won't go very far with it on Android, ChromeOS, iOS, iPadOS, mbed, Arduino, console OSes,...

The Arduino IDE calls out to avr-gcc, and mbed-os is written in c++ so requires an embedded c++ compiler like arm-gcc or something similar. ChromeOS also runs the Linux kernel so you do need it to compile the OS, and it can hypothetically run binaries compiled for the linux platform. Dig deep enough through all the layers of bootstrapping and you'll find c basically everywhere.

GCC is written in C++.

ChromeOS users don't compile their kernel.

Crostini is built with Rust and Go.

If making Bazel work on Windows is a side effect of Firefox using it, what's not to like about it.

Bazel already works on Windows.

"Works" can mean very different things on Windows. On one extreme you can have proper integration that covers Windows' idiosyncrasies such as automatically finding and setting up the Visual Studio environment instead of making the user jump through hoops like starting the dev command prompt. And on the other extreme you can have something hacky like "requires Cygwin" which I personally wouldn't even call "works".

It works in the best sense (no dev prompt, does not require cygwin)

Reply on news.ycombinator.com