Meson Build System

[Volker Weißmann]

Hello,

I'm a developer that worked quite a bit with the meson build system and looked at   sagemath for a few days. I thought that redoing the build system with meson instead of autoconf would be quite a bit of work, but would

1. Be far, far more readable.

2. Result in far faster incremental builds if very little has changed since the last build.

What do you think? Is this a good idea? Would you appreciate (and merge) such an endeavour?

Greetings

Volker

[Matthias Koeppe]

Hi Volker,

I would welcome using Meson (specifically meson-python) for building the Sage *library*, replacing our use of the very dated setuptools. Other scientific packages, notably SciPy have gone this route with great success. That's https://github.com/sagemath/sage/issues/34630, and I'll be happy to discuss more and collaborate on this.

This would have a great impact - faster compilation of the Sage library, proper tracking of dependencies, etc. 

On the other hand, I would be very reluctant to replace the autoconf + Makefile build system that drives the Sage *distribution*. A lot of work has gone into achieving the platform support that we currently offer, and on a short time scale, there is little to be gained by reimplementing all that. And in the medium/long term, as discussed in another sage-devel thread, I would hope that the Sage project can withdraw from its (historically important) role as a user-installable software distribution altogether because other projects, in particular conda-forge, are increasingly filling it.

[Michael Orlitzky]

Meson is my second favorite build system, but there are a few obstacles
to a rewrite:

* Autotools is nicer for end users, because all you need to run it is 
a posix shell. The tradeoff is that writing autotools sucks for 
developers. It is however already written.

* Related to the first item, meson has bootstrapping issues because 
it's written in python (which we use autotools to detect), and 
because meson sometimes introduces new features. If we use those
new features then users need newer versions of meson which need 
newer versions of python... This is offset somewhat by the fact 
that we already have a set of bootstrap dependencies but it would  
be one more thing we'd have to worry about. (There is also a C99
implementation of meson called muon.)

* The ./configure && make process is "standard" and familiar to 
everyone while meson is less so. This could change in a few years.

* The sage build system is perpetually in flux and it would be very 
hard to coordinate a rewrite.

And the big one:

* You probably haven't looked hard enough at the existing build 
system. We've got mountains of highly unusual autoconf code and 
hand-written Makefiles that all interact in weird ways with
sage's own package manager. Meson makes the standard build tasks
simple, but a lot of what we're doing is non-standard. Trying to
rewrite those bits in meson might only make things worse.

So I commend your bravery but I think you would waste a lot of time
before eventually giving up. And IMO the benefits would be dubious.

Some day we may reach a point where the sage library is an independent
package with its own standard ./configure script that just looks for
headers and libraries and substitutes strings into files. At that point
this would be a less crazy idea.

[Tobia...@gmx.de]

https://github.com/sagemath/sage/pull/36489 now implements a basic meson setup that replaces autoconf for sage library. Given the complexities mentioned above, I've restricted attention to when all the dependencies are provided via conda, which reduced the problem to something manageable. Thus, with this the build looks as follows: use conda to setup all dependencies, use meson to get a few config settings needed, then use setuptools to install sage library. Of course, the last step you ideally also want to replace with meson. Would love to collaborate on this.

[Volker Weißmann]

If you need help, I'm available and very familiar with meson.

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/D_Vv8dt811E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/82f72404-26f7-44a0-8ffc-a234f77e5b9fn%40googlegroups.com.

[Tobia...@gmx.de]

Awesome! I've continued working on it over at https://github.com/sagemath/sage/pull/36524, which uses meson to compile parts of sagelib. It seems to work fine so far and I didn't encounter any real trouble. Everything ranging from some cursory remarks to a full-fledged code review (of the meson build files) is very much appreciated. (What I cannot solve atm is some strange problem that cython cannot find cpython.type, most likely due to my missing knowledge - try to uncomment https://github.com/sagemath/sage/pull/36524/files#diff-32c42370ab1561aa94976dd31af60935f565de9758cf3aea132a9b73aaa95305R199 to see the error).

The next step is of course to compile larger and larger parts of sage with meson. Let me know if you are interested in contributing to this, and then we can coordinate.