Trial use of meson as build system

[halfflat]

Let's try meson! Dependencies are Python3 and Ninja, and in principle we can install it locally in our environments with Pip.

In the first instance, let's just trial it for a serial (no MPI) build.

Until (if ever) it becomes a robust alternative to the existing CMake scripts, CMake will be the preferred build system and the one which needs to be in a working state.

[bcumming]

I have a proof of concept for Meson in the following branch:

https://github.com/bcumming/arbor/tree/meson

It took one day to put together.

It compiles everything needed to build the ring example, i.e. modcc, mechanisms, libarbor, libsup, libenv.

The same effort would have taken a week and a lot of angst to do in CMake.

Still to resolved:

• CUDA support
• MPI
• setting flags specific to compilers (for simd)

[bcumming]

This is being revived after a lengthy hiatus.

I will develop a proof of concept, that demonstrates end to implementation of our build process that we can use to analyze whether meson is viable.

I will not support some features, like MPI or GPUs, to reduce the complexity of the demonstrator.

[brenthuisman]

What's the status of this?

[thorstenhater]

Trial is online as a draft PR. We still lack the most crucial part: Passing arguments from pip to cmake/meson (yes, neither!). Until this is fixed, meson isn't a valuable upgrade over cmake. Freezing this indefinitely until pip/python/setup.py/pyproject.toml get their act together.

[eli-schwartz]

We still lack the most crucial part: Passing arguments from pip to cmake/meson (yes, neither!).

pip has --config-settings but the backend needs to support this. https://pypi.org/project/meson-python/ can do this both on the command line and via a pyproject.toml setting.

[brenthuisman]

Thanks for chiming in @eli-schwartz. You can find our progress here: https://github.com/arbor-sim/arbor/pull/1991

As Arbor is not a pure Python project, currently meson-python is missing a crucial feature for us: "Link against libraries from the Meson project", since we would switch to Meson versions for some of our deps (I assume that's what you mean with 'libraries from the Meson project') and we ship an executable (script) in addition to the library.

Also, https://github.com/mesonbuild/meson/issues/7863 being open made us think the time isn't right for looking into this. Maybe that issue being open isn't the best indicator, but how 'complete' is meson-python?

[eli-schwartz]

It's not the best indicator IMHO. The meson-python backend is pretty complete, and currently being developed under the mesonbuild organization by the scientific python community (initially for SciPy and NumPy to use).

SciPy successfully released with it for a while now, as have some other projects.

...

The meson issue is about adding a simpler backend directly to Meson (the meson-python can do some stuff that auditwheel is usually used for!) and to an extent, about letting meson-python become a bit simpler by deferring some things to Meson's core. It's also vital for meson itself to build with meson, since obviously if "A" build-depends on "B" then "B" can't also build-depend on "A" -- hence meson cannot build-depend on meson-python.

What's probably going to happen is that the meson-python code is used as the base for merging into meson. A couple nitpicky details will be involved, like avoiding external dependencies (there's ongoing work to improve the python ecosystem so that dependencies such as packaging aren't a requirement for implementing a C extension supporting build backend). But for the moment, it's really just about where the code lives.

Again, meson-python is maintained as part of the @mesonbuild organization.