Live data from Hacker News

Moving SciPy to the Meson Build System

labs.quansight.org

1–10 of 34 posts

Re: Moving SciPy to the Meson Build System

#3
I'm using Meson for a project using C++ with Gtkmm, Libmicrohttpd, catch2 and other libraries. My experience is good neglecting some minor issues. Meson is fast, well readable if written well, uses system libraries by default and allows flexible usage.

On the other side I'm using Java with Maven and it is - a big burden. It's build in dependency retrieval system also isn't helping. Maybe I just don't like XML - because it is not human-readable ;)

Re: Moving SciPy to the Meson Build System

#4
post #3

I'm using Meson for a project using C++ with Gtkmm, Libmicrohttpd, catch2 and other libraries. My experience is good neglecting some minor issues. Meson is fast, well readable if written well, uses system libraries by default and allows flexible usage. On the other side I'm using Java with Maven and it is - a big burden. It's build in dependency retrieval system also isn't helping. Maybe I just don't like XML - becau…

I'm sorry to pick a nit, but could you expand on "well readable if written well"? I would say that a Makefile or even a CMakeLists.txt are readable if written well.

Re: Moving SciPy to the Meson Build System

#6
post #4
post #3

I'm using Meson for a project using C++ with Gtkmm, Libmicrohttpd, catch2 and other libraries. My experience is good neglecting some minor issues. Meson is fast, well readable if written well, uses system libraries by default and allows flexible usage. On the other side I'm using Java with Maven and it is - a big burden. It's build in dependency retrieval system also isn't helping. Maybe I just don't like XML - becau…

I'm sorry to pick a nit, but could you expand on "well readable if written well"? I would say that a Makefile or even a CMakeLists.txt are readable if written well.

For my part, I find that being written well is necessary but not sufficient for readability in a Makefile.

The other big one is that you need to have a strong familiarity with Make, and use it often. Familiar because there's no way a person who hasn't actually been through some form of Make documentation in detail can even guess at what things like $@, $?, and $^ do, or accurately decipher its macro replacement syntax, or any of that. And use it often because, even if you were deeply familiar with Make in the past, if you haven't touched it in a few years, you're unlikely to reliably remember it without help.

Re: Moving SciPy to the Meson Build System

#7
post #5

How does Meson compare to other build systems like bagel?

It is Cmake with Python syntax.

Meson internals have nothing to do with cmake, and the syntax is not python.

If you want to make that comparison, meson is more restrictive than cmake, but tends to have more functionality built-in to make up for it.

bazel is more all-encompasing than either, as it's more about reproducible and distributed builds than a "better makefile" type system.

Re: Moving SciPy to the Meson Build System

#8
post #5

How does Meson compare to other build systems like bagel?

It is Cmake with Python syntax.

That doesn't strike me as a good characterization. Especially because both Python and Cmake are quite imperative. Meson is declarative with an emphasis on immutability.

It's "cmake in role only" - both are build systems, that's where the similarity falls apart.

The syntax is very pythonic, however, I think that's true of many ergonomic centric formats.

Post reply on HN