Moving SciPy to the Meson Build System

For me, Gradle's readability depends heavily on how you use it.

If you use it Maven-style, with relatively simple build scripts and all the complexity pushed out to plugins, it's very readable. A fair bit more readable than Maven, in my opinion, but I wouldn't care to argue that point in particular.

If you use it the way Stack Overflow tells you to do it, so that your build scripts are basically glorified ad-hoc Groovy programs, then, yeah, it's just impossible.

Unfortunately, since the only way to really understand any of Gradle is to understand all of Gradle, and understanding all of Gradle is a huge effort, it's kind of a catch-22. For most people, the only really sensible way to use it is to Google for advice and then do what Stack Overflow tells you to do. But that invariably leads to a result that is not even remotely sensible.

Long story short, my hot take is this. Maven is write-only. Gradle (ideal usage) is read-only. Gradle (normal usage) can be neither read nor written.

nix-build relies on symlinks, which seemingly can't work on Windows. And it's not really a build system. Bazel relies on a JVM and it's really nice to not have one of those on your system if you don't absolutely need it.

Depending on how minimal you want to get, I think native build systems where you're not just building for yourself, but distributing source bundles that need to be built by others, have to start the discussion with Autotools, CMake, and Meson. The reason is just that they're already required by everything else anyway, so you're not adding any burden to the downstream packagers by using them.

If you're just building for yourself, have at it, get as bespoke and obscure as you want, but SciPy isn't being built and deployed primarily on NumFOCUS's own servers. It's being distributed as a tarball to its users who mostly build it themselves. You should make every effort to use a build system they're likely to already have and already be familiar with.

In particular, much of the focus here seems aimed at users who want to cross-compile for embedded Linuxes running on ARM. I doubt those people want to pull in a JVM.

Kind of reminds me of when I was working for a geointelligence agency charged with building and integrating third-party ground processing algorithms into a user-facing web tasking framework. We have to retrieve and build the dependencies, too. xerces-c, Armadillo, MKL, no problem. Just keeping downloading, either cmake .. or configure, make, then make install, over and over.

Then one of them requires TensorFlow and it becomes a two-month research project trying to figure out how to build it (sorry Google, but the military does not trust your pre-built binaries).