SageMath Now Supports Meson – Faster and More Efficient Builds!
Tobia...@gmx.de
Dear developers,
I am excited to announce that SageMath now supports the Meson build system! This modern alternative to Autotools brings several key advantages:
- Faster Builds – Meson significantly reduces configuration and compilation time due to better parallelism (some benchmark claim up to 20% reduction of compilation time; in my experience it was closer to 10%)
- Better Incremental Builds – Only necessary files are recompiled, speeding up development. In particular, Meson will automatically recompile Cython files when they change - without the need to run `sage -b` or similar commands. The workflow is thus the same as for Python files: a) make the necessary changes b) save the file c) run the tests (which then automatically use the freshly recompiled version)
- Easier Installation – Meson works smoothly with the standard Python packaging systems, so that the installation of Sagemath using Meson is a simple `pip install .`; no more bootstrap + configure + make.
-
Cross-Platform
–One of the biggest advantages of Meson is that it natively supports Windows (in addition to Linux and MacOS, of course). This opens up a direct road to natively use Sage on Windows; in fact, https://github.com/sagemath/sage/pull/38872 is the first step towards this goal.
-
Easier Dependency Management – External dependencies / system packages are detected more reliably (caveat: some of the extra feature checks are not yet reimplemented in Meson).
To build SageMath with Meson, install the required dependencies (either using your system package manager or conda), then use:
`pip install --no-build-isolation --editable .`Start Sage with `./sage` and run tests using `./sage -t`, as usually.
For more details, check out the SageMath Meson Guide.
William Stein
Congrats and fantastic! Is it possible that you could add some
additional "human context" for those of us on the sidelines, e.g., who
added Meson support to Sage (you?), why?, how hard what is and how
long did it take?, what was involved? Also, to what extent does Meson
replace autotools? E.g., there are many packages in Sage that use
autotools -- does this mean that all of them have a non-autotools
build process as well now?
Thanks for whatever quick context you can easily provide,
William
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/sage-devel/6aef0674-5f4a-4576-85e8-f80506ea232fn%40googlegroups.com.
--
William (http://wstein.org)
Dima Pasechnik
> Congrats and fantastic! Is it possible that you could add some
> additional "human context" for those of us on the sidelines, e.g., who
> added Meson support to Sage (you?), why?, how hard what is and how
> long did it take?, what was involved? Also, to what extent does Meson
> replace autotools? E.g., there are many packages in Sage that use
> autotools -- does this mean that all of them have a non-autotools
> build process as well now?
The Meson builds are only done for sagelib, and for some other
sagemath Python projects, such as
https://github.com/sagemath/cysignals
More Python things in https://github.com/sagemath/ need an update of
the build system, away from distutils/setuptools "python setup.py"...
I don't think we're going to push any meson to upstream projects, in
particular certainly not to non-Python ones.
Dima
Tobia...@gmx.de
Thanks for your interest, William!
The Meson project for Sage began in October 2023 (PR #36524), and most of the work was wrapped up a couple of months ago. I just wanted to iron out a few remaining annoyances before officially announcing it on the mailing list.
My original motivation was to enable native builds of Sage on Windows. Moreover, I had grown increasingly frustrated with constant build issues in sage-the-distribution. Around the same time, many other projects in the ecosystem, like NumPy/SciPy and flint-python, had started migrating to Meson as well, which reinforced the idea.
The majority of the work and PRs came from my side, but I’m very grateful for the interest and support from the community — especially those who reviewed, tested, or otherwise contributed. A big thank you to Dima, Michael, Gonzalo, Antonio, and “user202729” in particular!
As Dima mentioned, currently only sagelib has been migrated. It can now be built completely independently of any autotools/configure/bootstrap scripts.
Regarding dependencies, there are a few strategies:
a) Require dependencies to be installed externally (e.g., via a system package manager or Conda).
b) Make non-essential dependencies optional — if not present, Meson simply skips building the corresponding Cython modules, in a fine-grained way.
c) Use Meson’s subproject feature to automatically build missing dependencies. Ideally, this involves writing a Meson build system for the subproject, but sometimes an upstream CMake or Autotools build system can be reused.
Currently, we’ve mostly implemented strategy (a). For this reason, I recommend installing dependencies via Conda or using a Linux distro that ships recent-enough versions, like Arch or Gentoo.
For Windows support, I used a combination of (b) and (c) as well, since some dependencies can’t be built on Windows at all or aren’t yet available via Conda. For example, I wrote a Meson build script for Singular, and reused the upstream CMake build for Flint.
I’m curious to hear what others think would be a good approach when a required dependency isn’t available on the system — especially in the context of portability and developer experience.
Dima Pasechnik
<sage-...@googlegroups.com> wrote:
>
> Thanks for your interest, William!
>
> The Meson project for Sage began in October 2023 (PR #36524), and most of the work was wrapped up a couple of months ago. I just wanted to iron out a few remaining annoyances before officially announcing it on the mailing list.
>
> My original motivation was to enable native builds of Sage on Windows. Moreover, I had grown increasingly frustrated with constant build issues in sage-the-distribution. Around the same time, many other projects in the ecosystem, like NumPy/SciPy and flint-python, had started migrating to Meson as well, which reinforced the idea.
>
> The majority of the work and PRs came from my side, but I’m very grateful for the interest and support from the community — especially those who reviewed, tested, or otherwise contributed. A big thank you to Dima, Michael, Gonzalo, Antonio, and “user202729” in particular!
>
> As Dima mentioned, currently only sagelib has been migrated. It can now be built completely independently of any autotools/configure/bootstrap scripts.
>
> Regarding dependencies, there are a few strategies:
>
> a) Require dependencies to be installed externally (e.g., via a system package manager or Conda).
> b) Make non-essential dependencies optional — if not present, Meson simply skips building the corresponding Cython modules, in a fine-grained way.
> c) Use Meson’s subproject feature to automatically build missing dependencies. Ideally, this involves writing a Meson build system for the subproject, but sometimes an upstream CMake or Autotools build system can be reused.
>
> Currently, we’ve mostly implemented strategy (a). For this reason, I recommend installing dependencies via Conda or using a Linux distro that ships recent-enough versions, like Arch or Gentoo.
>
> For Windows support, I used a combination of (b) and (c) as well, since some dependencies can’t be built on Windows at all or aren’t yet available via Conda. For example, I wrote a Meson build script for Singular, and reused the upstream CMake build for Flint.
>
> I’m curious to hear what others think would be a good approach when a required dependency isn’t available on the system — especially in the context of portability and developer experience.
relatively rare on distros, yet relatively easy to install. E.g.
Fricas.
Which is not on Conda, but can be built from source, assuming sbcl is
installed, or with an explicit option to install using ecl.
To justify creation of a python package with it, one would have to
spin out some Python interface to it.
One way or another, perhaps the better way to install Sage would be to
create a pipx Sage package - pipx is basically pip, but for console
Python applications,
so this is something fitting for Sage.
Dima