> Really there were only two viable candidates: CMake and Meson.
Would be great to hear why those were the only two candidates that they considered (and not e.g. Bazel or Nix).
Would be great to hear why those were the only two candidates that they considered (and not e.g. Bazel or Nix).
I suspect Bazel was ruled out because it requires the JVM and it has limited open source uptake relative to CMake (huge open source userbase), and Meson (limited presence in open source scientific software, but adopted by GNOME and systemd).
Based on that, I just sort of assumed that, in addition to all the fairly well-documented up-front challenges that these folks had identified and were talking about, there must also be some impassable barrier lurking around in there that nobody finds until they've already sunk a lot of time and money into trying to get it working. I don't know what that is, and I'm not curious enough to spend the better part of a year trying to find it for myself. I ended up choosing Gradle.
It went from “maybe run stdlib Python in an activated venv“ to actually working.
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).