9 ms·

> 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.

by rkrzr 5y ago

> 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).

chromatin 5y ago
Yes, perhaps it is true, and it is obvious to build experts, but as a novice in this area (build systems), I would love for some more exposition.
- flohofwoe 5y ago
  One typical problem for C/C++ build systems is lack of proper Windows and MSVC toolchain support. Most C/C++ build systems originated in the UNIX world, and either only support GCC-compatible toolchains or if they support MSVC then only as an afterthought. Trying to get this stuff running in a Windows environment is often a mix of frustation and plain hilarity. CMake is one of the few build tools that gets Windows and MSVC support right.
rjsw 5y ago
Haven't read the article but meson will run on a lot more systems than bazel.
ihnorton 5y ago
Nix is likely a nonstarter because as far as I can tell it does not natively support Visual Studio and MSVC. 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).
- mumblemumble 5y ago
  I can't speak for scipy, but I ruled Bazel out for a project that included Python components a few years ago. It was great for C, C++, and Java projects, but, at least at the time, there was no official Python support. I looked into third-party options and the feasibility of building it myself. Most of what I found was a few different conference talks and blog posts where the presenter was enthusiastically talking about how they'd spent a year trying to get it to work and it's not quite there yet but they're feeling really really confident that they'll turn a corner sometime soon. But I could never find any subsequent evidence that the presenter's team actually had turned that corner. 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.
  - dfinninger 5y ago
    Our team started moving to Bazel two years ago with 0.21 or something. Python support is much, much better these days. We’re building Python with requirements and packing it into Docker containers. It went from “maybe run stdlib Python in an activated venv“ to actually working.
    - mumblemumble 5y ago
      That's great to hear. Yeah, 2 years ago would have been after I made this decision. Looking forward to taking another look at Bazel; I strenuously wanted it to be the one.
  - prpl 5y ago
    What was your artifacts and what did you choose instead?
    - deleted 5y ago
      [deleted]
prpl 5y ago
SciPy is a multi platform library that is distributed, most famously on pypi but in many other ways (conda, spack, rpm, deb, etc…). How can nix handle that without requiring the user to install nix?
chpatrick 5y ago
Nix works at a higher level and usually invokes CMake, make, Meson, etc. It doesn't have its own C/C++ build system.
nonameiguess 5y ago
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).

by rkrzr 5y ago

> 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).

chromatin 5y ago

Yes, perhaps it is true, and it is obvious to build experts, but as a novice in this area (build systems), I would love for some more exposition.

flohofwoe 5y ago
One typical problem for C/C++ build systems is lack of proper Windows and MSVC toolchain support. Most C/C++ build systems originated in the UNIX world, and either only support GCC-compatible toolchains or if they support MSVC then only as an afterthought. Trying to get this stuff running in a Windows environment is often a mix of frustation and plain hilarity. CMake is one of the few build tools that gets Windows and MSVC support right.

rjsw 5y ago

Haven't read the article but meson will run on a lot more systems than bazel.

ihnorton 5y ago

Nix is likely a nonstarter because as far as I can tell it does not natively support Visual Studio and MSVC. 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).

mumblemumble 5y ago
I can't speak for scipy, but I ruled Bazel out for a project that included Python components a few years ago. It was great for C, C++, and Java projects, but, at least at the time, there was no official Python support. I looked into third-party options and the feasibility of building it myself. Most of what I found was a few different conference talks and blog posts where the presenter was enthusiastically talking about how they'd spent a year trying to get it to work and it's not quite there yet but they're feeling really really confident that they'll turn a corner sometime soon. But I could never find any subsequent evidence that the presenter's team actually had turned that corner. 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.
- dfinninger 5y ago
  Our team started moving to Bazel two years ago with 0.21 or something. Python support is much, much better these days. We’re building Python with requirements and packing it into Docker containers. It went from “maybe run stdlib Python in an activated venv“ to actually working.
  - mumblemumble 5y ago
    That's great to hear. Yeah, 2 years ago would have been after I made this decision. Looking forward to taking another look at Bazel; I strenuously wanted it to be the one.
- prpl 5y ago
  What was your artifacts and what did you choose instead?
  - deleted 5y ago
    [deleted]

prpl 5y ago

SciPy is a multi platform library that is distributed, most famously on pypi but in many other ways (conda, spack, rpm, deb, etc…). How can nix handle that without requiring the user to install nix?

chpatrick 5y ago

Nix works at a higher level and usually invokes CMake, make, Meson, etc. It doesn't have its own C/C++ build system.

nonameiguess 5y ago

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).