Distributions

Moving Mesa to Meson

Developers have been building code with Autotools and make since before Linux was created — and they have been grumbling about these tools for nearly as long. Complaints notwithstanding, viable replacements for these tools have been scarce; attempts in this area (remember Imake?) have gained limited traction. Recently, though, Meson has been getting some attention. But changing build systems is never an easy decision for an established project, as can be seen in a recent discussion in the Mesa community. While there are several sticking points, one of the key issues would appear to be the effect on distributors.

On March 16, Dylan Baker opened the can of worms by posting a patch series switching the libdrm library's build system to Meson. While there are a number of claimed advantages to moving libdrm over, the stated purpose of this exercise was "practice for porting Mesa", so the Mesa community was included in the discussion. The advantages of this move, Baker said, include faster builds (thanks partly to the use of Ninja for the actual build work), a simpler build system in general, and moving to a system with an active community to maintain it.

Most projects only support a single build system; Mesa stands out by supporting three of them. Autotools and make are employed on Unix systems, SCons on Windows (or optionally Linux), and Android has its own build system. One might argue that Mesa is thus a prime candidate for adding yet another but, strangely, the project's developers have come to the conclusion that they have enough build systems already. So the hope would be that, by adopting Meson, the project could drop at least one of the other systems.

One of the reasons for all of those build systems is the wide use of Mesa; it is far from a Linux-only project. So it is natural for Mesa developers to worry about how a change of build system might affect downstream distributors of the code. There are some low-level concerns that Meson might not integrate well into distributor build procedures. It apparently has an annoying habit of mixing standard output and standard error from the build into a single stream, for example, and it requires the use of a separate build directory. One assumes that these issues could be dealt with somehow.

The bigger concern had to do with support for Meson on non-Linux systems. Mesa release manager Emil Velikov asserted, for example, that "VMWare people like their SCons and that Meson is not supported on BSD systems or Android. As a result, he does not appear to see much value in making a change. With regard to VMware, nobody from that company has spoken out on the change. The situation with the other systems may not be as bad as portrayed here either.

BSD appears to be better supported than Velikov thought: Baker did some research and found that Meson is available for FreeBSD, NetBSD, and OpenBSD. He couldn't find a Solaris package, "but there is ninja for Solaris, and meson itself is pure python installable via pip, so even there it's not impossible". The OpenBSD situation seems to be a bit more complicated, though, since Mesa is part of its core system build, while Meson is not. There was some discussion of how much needs to be done to support OpenBSD; some developers clearly see OpenBSD (and its old compiler) as being a drag on the Mesa project as a whole.

In any case, it seems clear that the BSD systems could adapt to the use of Meson if they had to. And it seems that they may well have to, regardless of what Mesa does. The GNOME community has been looking at making the switch for a while, for example. The X server is working on a move, as are libinput, GStreamer, and Wayland and Weston. Any distributor (Linux or otherwise) wanting to ship those packages is going to have to find a way to work with Meson at some point. It may not even be a particularly hard sell, since developers who work with Meson seem to find it to be easier to work with than the alternatives.

As is so often the case, the situation with Android is unclear. Android appears to be moving over to a new build system of its own called blueprint which, like Meson, uses Ninja to do the actual builds. In any case, it seems that Android will continue to do its own thing, regardless of how Mesa is built for other platforms.

Alex Deucher worried that a switch to Meson could discourage casual contributors. While "autotools isn't great", he said, there are a lot of developers with experience using it and resources available on the net. Meson may not benefit from so much experience and, if it discourages casual users from trying to build the system, that would be a big cost to pay. But Eric Anholt isn't worried about that:

Overall, the discussion seemed favorable to the idea of moving to a new build system, but only if the result was the quick removal of support for at least one other system. Which one would go first is not clear, though. Rob Clark suggested getting rid of SCons first, but Baker appears to be leaning toward replacing Autotools and make as the first step:

The next step in that plan, of course, is to create patches to convert the entire Mesa library over to the new build system and evaluate the results. If, as seems likely, this experiment goes well, it may prove to be one of the first in a lengthy series of migrations away from a build system that is older than many of the developers using it. Even distributors may well conclude that switching over is worth dealing with the short-term pain.

Comments (13 posted)

Distribution quotes of the week

— Shane

— flexiondotorg

Comments (1 posted)

DragonFly BSD 4.8

DragonFly BSD 4.8 has been released. "DragonFly version 4.8 brings EFI boot support in the installer, further speed improvements in the kernel, a new NVMe driver, a new eMMC driver, and Intel video driver updates." DragonFly is an independent BSD variant, perhaps best known for the HAMMER filesystem.

Comments (none posted)

Maru OS 0.4

Maru OS 0.4 has been released. This version adds support for the Nexus 7 2013 Wi-Fi (flo). "Additionally, Maru OS now supports full-disk encryption of both your mobile and desktop data." See the changelog for details.

Comments (none posted)

Oracle Linux Release 6 Update 9

Oracle has released version 6.9 of Oracle Linux. See the release notes for more information.

Full Story (comments: none)

Ubuntu 17.04 (Zesty Zapus) Final Beta released

Ubuntu has released the final beta of Zesty Zapus (17.04) for Ubuntu Desktop, Server, and Cloud products, as well as Kubuntu, Lubuntu, Ubuntu GNOME, UbuntuKylin, Ubuntu MATE, Ubuntu Studio, and Xubuntu flavors.

Full Story (comments: 1)

Debian Bug Squashing Party (BSP) in Zurich (May 5-7, 2017)

There will be a Bug Squashing Party May 5-7 in Zurich, Switzerland. "Everyone who wants to contribute to the next Debian release is welcome. You don't need to be a Debian Developer to contribute: You can e.g. try to reproduce release-critical bugs, figuring out under which circumstance they appear, or even find patches to solve them."

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly (March 27)
• KaOS news (March)
• Lunar Linux weekly news (March 24)
• Mageia Weekly Roundup (March 24)
• openSUSE Tumbleweed Review of the week (March 24)
• Sparky news (March 29)
• Ubuntu Kernel Team newsletter (March 21)
• Ubuntu Weekly Newsletter (March 26)

Comments (none posted)

Manjaro: User-Friendly Arch Linux for Everyone (Linux.com)

Jack Wallen reviews the Arch derivative, Manjaro. "In the end, I think it’s safe to say that Manjaro Linux is a distribution that is perfectly capable of pleasing any level of user wanting a reliable, always up-to-date desktop. Manjaro has been around since 2011, so it’s had plenty of time to get things right… and that’s exactly what it does. If you’ve been looking for the ideal distribution to help you give Arch a try, the latest release of Manjaro is exactly what you’re looking for."

Comments (none posted)

The Zephyr Project: An RTOS for IoT (TechTarget)

TechTarget takes a look at the Zephyr Project, which is a modular, scalable platform designed for connected, resource-strained devices. The open source RTOS is based on the Wind River Rocket IoT OS technology acquired by Intel. "Unlike many of the emerging RTOSes and open IoT OSes that differentiate on the basis of functionality, the Zephyr Project is taking a page out of the Linux playbook, touting its open source governance and licensing model along with its community-based ecosystem as the primary advantages of the platform. While many RTOSes are linked to a specific architecture, the Zephyr IoT OS targets an array of small hardware devices, including Arduinos and ARM SoCs, and is able to serve as a general-purpose OS, unlike many alternative RTOSes, which are limited in functionality or are highly specialized, experts said."

Comments (none posted)