GNOME Shell 3.25.4 Adds Meson Build System Support

[phoronix]

Phoronix: GNOME Shell 3.25.4 Adds Meson Build System Support

With the GNOME 3.25.4 development milestone this week, new versions of GNOME Shell and Mutter are among the packages checked-in for release...

http://www.phoronix.com/scan.php?pag...-Mutter-3.25.4

[GrayShade]

Does anyone know the story of how Meson got to take over the freedesktop.org project?

[kmare]

Cool, apparently mutter also added fractional scaling!

* Support fractional monitor scaling [Jonas, Marco; #765011]

[bkor]

Does anyone know the story of how Meson got to take over the freedesktop.org project?

It's something which is easier than autotools without the problems people saw with cmake/waf/etc. This with meson really working easily with the various build items that are used. E.g. great integration with pkgconfig. Meson maintainers are actively working to fix any issues and intend to make it as easy to use.

[okias]

Does anyone know the story of how Meson got to take over the freedesktop.org project?

I rewritten original iputils Makefile with minimal Makefile knowledge and no Meson knowledge in few hours.
Code looks much cleaner than original Makefile, it still missing some advanced options, but I'll look into them soon (and I guess it will be still easier and very well readable file)..

[Veerappan]

Meson is easy(-ish) to use, supports easy cross-platform portability, is much more understandable than autotools, and it's fast when coupled with something like ninja. Couple that with the previous statements about how active and receptive the maintainers are to enhancement requests and bug reports, and it's easy to see why people like it.

[zeehio]

Does anyone know the story of how Meson got to take over the freedesktop.org project?

Part of the meson development has been to try to convert some big projects, and detect and implement missing meson features. For instance here it is stated some intention of releasing meson v1.0 after GStreamer is properly supported.

I find their decisions very sensible, and their way of developing meson is also good. The main reason most projects do not drop autotools are:

- switching the build system is time consuming and requires learning new tools
- autotools was/is the de-facto standard build system (CMake competes)
- non-autotools build systems do not provide the features they need

If:
- You have a meson contributor helping in the conversion
- You can get fast feedback and bug/feature fixes in meson, with easy installable releases via `pip`.
- There is good documentation with official well written examples
- Other big projects have similar help and seem to consider switching

Then you say:
- "hey, someone has been doing the build system conversion for us and has implemented in the build system the features we needed" (see here)
- "hey, meson is faster than autotools" (see here)
- "hey, others are finally switching... maybe we can switch as well"
- "hey, meson seems easy to understand"
- "hey, we can easily keep both build systems coexisting for a while"
- "hey, mandatory out of tree builds are a good idea"

When others follow, meson breaks the autotools inertia and succeeds in becoming a good autotools replacement.

While it is possible to argue that CMake was able to do all of that, I would say that to me meson seems easier to understand than CMake. Despite this opinion, if you consider CMake is as good or better than meson, the question to answer is "Why were there so many projects still with autotools after several CMake years?"

[caligula]

While it is possible to argue that CMake was able to do all of that, I would say that to me meson seems easier to understand than CMake. Despite this opinion, if you consider CMake is as good or better than meson, the question to answer is "Why were there so many projects still with autotools after several CMake years?"

These new 16+ core machines should really help in putting the blame on gnu autohell. The modern machines build stuff lightning fast with make -j16 or -j32. The autohell part is already the slowest part of compiling many packages.