Wayland Adds Meson Build System Support

[ascent12]

The Meson build support was added to the official Wayland project (last commit of Jan 10). There are a grouping of core Wayland libraries that are used by the other projects to build their window managers/compositors. It still retains its autotools build system.

https://gitlab.freedesktop.org/wayla...commits/master

If it was added by a GNOME dev, it was likely to help them push for a unified build system, as the GNOME project has been utilizing Meson for some time now and pushing to have all of their subprojects (except evolution) using it: https://wiki.gnome.org/Initiatives/G...s/MesonPorting

A GNOME specific Wayland project does not exist on the GNOME GitLab instance, it's all in Mutter (afaik). This was a contribution to a non-GNOME project.

Cheers,
Mike

The decision to use Meson has nothing to do with Gnome. It's honestly just a nicer build system, and you'll see that it has massively taken over the linux graphics space.

[ascent12]

Help me understand something. When people complain Wayland doesn't support this and that, it gets pointed out that Wayland is just a protocol and it's the concrete implementation that's the problem. If Wayland is just a protocol, why does it need meson?

libwayland is the library that deals with the low-level wire protocol, which is actually the stream of bytes that get sent. The wayland protocol and extensions to it use this library, although alternative implementations of libwayland exist.

[duby229]

The Meson build support was added to the official Wayland project (last commit of Jan 10). There are a grouping of core Wayland libraries that are used by the other projects to build their window managers/compositors. It still retains its autotools build system.

https://gitlab.freedesktop.org/wayla...commits/master

If it was added by a GNOME dev, it was likely to help them push for a unified build system, as the GNOME project has been utilizing Meson for some time now and pushing to have all of their subprojects (except evolution) using it: https://wiki.gnome.org/Initiatives/G...s/MesonPorting

A GNOME specific Wayland project does not exist on the GNOME GitLab instance, it's all in Mutter (afaik). This was a contribution to a non-GNOME project.

Cheers,
Mike

Ah, ok. That makes sense. So dynamic libraries implementing the wayland protocol. I knew something like this must have existed due to reading years ago that wayland devs had decided early on to use code as documentation with explanation being that too much technical documentation can harm large projects. But I had always assumed, wrongly i guess, that code was imported into the compositor and built as part of the compositor binaries.

[mroche]

Yup, just thinking the same thing. Since the article specifically pointed out a Gnome dev, I have to assume it is talking about Gnomes implementation of wayland. It's probably unrelated to KDE or any other wayland compositor. Wayland isn't the thing, the compositor is the thing, so I think he's talking about Gnome.

The Meson build support was added to the official Wayland project (last commit of Jan 10). There are a grouping of core Wayland libraries that are used by the other projects to build their window managers/compositors. It still retains its autotools build system.

https://gitlab.freedesktop.org/wayla...commits/master

If it was added by a GNOME dev, it was likely to help them push for a unified build system, as the GNOME project has been utilizing Meson for some time now and pushing to have all of their subprojects (except evolution) using it: https://wiki.gnome.org/Initiatives/G...s/MesonPorting

A GNOME specific Wayland project does not exist on the GNOME GitLab instance, it's all in Mutter (afaik). This was a contribution to a non-GNOME project.

Cheers,
Mike

[boxie]

Thats equally nasty, either use makefiles or autotools properly :^)

I will admit an element of nasty is in there with my fun poking.

as for using makefiles or autotools properly - it appears that quite competent developers either cannot make it go faster or just don't care spending the time to do so when there are options that make it go faster with much less time involved.

I can see the benefit of not having to argue with tooling to make it go fast when there is an option that doesn't require arguing with to do the same job

[computerquip]

I think my biggest issue with meson is their mentality.

For example, if you want to use a portion of your codebase in both an executable and a shared library, you have to add specific flags to the compiler to make sure it doesn't optimize away object files when linking into a shared library if you compile it as a static library first. The right way of dealing with this is to deal with the object files directly which is rather portable across compilers. CMake supports this directly with object libraries. Meson has intentionally and specifically avoided this feature. Instead, you have to create a static library, even if you have no intention of using it as a static library, and fetch the object list associated with that library. If the object list isn't small, you've just wasted quite a bit of time making a library you don't even want. It feels like a hack because it is.

For another example, they often boast about their support for cross-compiling. However, if you try to cross-compile with anything that doesn't use the GNU-style CLI, you're completely out of luck. Using Meson to cross-compile with VC++ for example is impossible since their format simply doesn't allow it (at least when I last used it).

When at least one of my goals in using a build-system like Meson is to abstract away different compilers, I think Meson has failed miserably.
As of now, I don't think there's any valid competition for the usability CMake provides in creating a cross-platform and cross-compiler solution unfortunately. That said, I'm not a fan of the mixed declarative/procedural style language that CMake uses and it's definitely difficult to use in a team effort where not everyone may be as experienced as I am in the language or tools.

[duby229]

Help me understand something. When people complain Wayland doesn't support this and that, it gets pointed out that Wayland is just a protocol and it's the concrete implementation that's the problem. If Wayland is just a protocol, why does it need meson?

Yup, just thinking the same thing. Since the article specifically pointed out a Gnome dev, I have to assume it is talking about Gnomes implementation of wayland. It's probably unrelated to KDE or any other wayland compositor. Wayland isn't the thing, the compositor is the thing, so I think he's talking about Gnome.

[caligula]

When exactly would I prefer this? If I want to get rid of ninja's c++ library dependency I would just add '--static-libstdc++'

How long till samurai will support c++ modules? Cmake + ninja already have working solutions (dyndep feature of yet unreleased ninja version 1.10)

It schould have been rewritten in rust, wouldn't make it any better, but phoronix would gloat about it 😂

Both C++ and Python are unnecessary complex heaps of code and preset bad language design. While C is terribly unsafe, it has the advantage that it's ubiquitous and compact as C binaries often depend on core libs that are always there. Rust would be an acceptable update path providing both a safer language for application development and performance. The increase in size is acceptable when you get the other benefits.

[discordian]

As an alternative to ninja, there's also samurai ( https://github.com/michaelforney/samurai ) which is officially supported by meson ( https://github.com/mesonbuild/meson/issues/3405 ). It's written in C and has a small Makefile for building it.

When exactly would I prefer this? If I want to get rid of ninja's c++ library dependency I would just add '--static-libstdc++'

How long till samurai will support c++ modules? Cmake + ninja already have working solutions (dyndep feature of yet unreleased ninja version 1.10)

It schould have been rewritten in rust, wouldn't make it any better, but phoronix would gloat about it 😂

[caligula]

False claim, Alpine is smaller than most distros, even with python.
In other words, you're using a bloating distro and blame python.

Alpine isn't always an option since it uses a non-standard libc. Other than that, meson is more bloated even on Alpine:

make: 233472 bytes

meson + ninja + py3-setuptools: 8105984 bytes

3300% increase in size.