Dealii: consider using the meson build system

Created on 22 Jul 2020  路  5Comments  路  Source: dealii/dealii

I suggest that the project adopt the Meson build system as this latter is more well designed and easier to maintain and is cross-platform for all major OS.

Meson is now used by many major free software projects like Mesa3D[1] and Gnome.

I have personally used both cmake and meson and in my experience cmake is horrible to use and often broken. Because of the cmake quirks people needs to write more and more cmake configuration code and it can quickly become very difficult to manage and create a barrier to contribution.

Some people argues that C++ projects should use CMake because this latter is the de-facto standard but I consider that a build system should be chosen based on its qualities and not on the fact that "everyone else use it".

Here a project, libui that recently switched to Meson. Here a quote from the README of libui:

The build system has been switched to Meson. See below for instructions. This change was made because the previous build system, CMake, caused countless headaches over trivial issues. Meson was chosen due to how unproblematic setting up libui's build just right was, as well as having design goals that are by coincidence closely aligned with what libui wants.

Here also another blog post about switching to Meson from CMake.

[1] [https://lwn.net/Articles/718287/](https://lwn.net/Articles/718287/)

Build system

Most helpful comment

I think you should gradually introduce Meson alongside with Cmake.

I agree with the points @tamiko made. It is a major undertaking (we are talking hundreds of hours) and I don't think we have a volunteer to do the work. On top of that, a switch has several disadvantages (see above) so it is not clear to me if this makes any sense. Therefore, I am also against a switch even if done gradually.

All 5 comments

I think no one will argue with the major point you make, i.e., that meson is the clearly better and saner design. If it would have been available 10 years ago (and would have been on the level of maturity it is now) we would have likely selected it when we replaced the old autoconf and hand written makefile build system we had before.

Our CMake build system was written about 9 years ago targeting cmake-2.8.8. You can imagine how old this is even for CMake standards. Most of our CMake code (about 7000 SLOC with about 5000 lines of comments) consists of (a) detection of external libraries, (b) testing for compiler features and bugs. A surprising 2000ish SLOC are just related to verbose error messages.

Rewriting the current build system in meson is a major undertaking that would in addition require us to also rewrite the entire testsuite (because we use some evil cmake hacks + ctest for that) and then to update all our CI and testing infrastructure.
Worse, all of our users are now acquainted with cmake and would have to relearn a different build system.

And now the honest question is for what? The current build system works reasonably well.
I fully agree that CMake script is horrendous and that CMake itself is signficantly less declarative than it could be - but, lucky enough, not many people have to look at it :smile_cat: For the most part it works reasonably well, and we have found some good procedures and conventions to ensure maintainability - at least it worked for about 9 years now.

[1] Sure, if you just want to compile the library with meson for your particular configuration you can pull that of in a couple of days - the real pain comes from the fact that we support many different configurations and use cases.

I think you should gradually introduce Meson alongside with Cmake. In this way you don't need to replace cmake right away and you may begin to flesh out the Meson config. It will also easy for people to contribute gradually to the meson config, one step at a time.

At the beginning only cmake will be the official build system and meson will be used only by people that wants to. In this way you don't get the pressure to support with meson all the possible use cases from the first day.

Why you closed the issue because giving the opportunity to reply ?

I think you should gradually introduce Meson alongside with Cmake.

I agree with the points @tamiko made. It is a major undertaking (we are talking hundreds of hours) and I don't think we have a volunteer to do the work. On top of that, a switch has several disadvantages (see above) so it is not clear to me if this makes any sense. Therefore, I am also against a switch even if done gradually.

Ok thank you all for the feedback. I still do not agree but, hey, you are the owner of the project!

Kind regards
Francesco

It isn't that we are the owners of the project. It's that you are asking us to put hundreds of hours of work into a project that might lead to cleaner code but has otherwise no real benefit. Cmake, for all of its quirks, reliably does what we want, is cross-platform, is widely used, interacts reasonably well with all of the other projects that use cmake, and interacts well with IDEs. Other than "more modern", what would we gain by switching to meson? Who is going to pay for the time you're asking us to put into this project and why?

Now, if you were to volunteer, then that would be a different issue :-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tamiko picture tamiko  路  5Comments

adamqc picture adamqc  路  3Comments

drwells picture drwells  路  6Comments

davydden picture davydden  路  5Comments

bangerth picture bangerth  路  6Comments