Originally posted by mroche
View Post
Announcement
Collapse
No announcement yet.
Wayland Adds Meson Build System Support
Collapse
X
-
-
Originally posted by bug77 View PostHelp 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?
Leave a comment:
-
Originally posted by mroche View Post
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
- Likes 1
Leave a comment:
-
Originally posted by duby229 View Post
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.
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
- Likes 1
Leave a comment:
-
Originally posted by Redfoxmoon View Post
Thats equally nasty, either use makefiles or autotools properly :^)
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
Leave a comment:
-
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.
- Likes 2
Leave a comment:
-
Originally posted by bug77 View PostHelp 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?
- Likes 1
Leave a comment:
-
Originally posted by discordian View PostWhen 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 😂
Leave a comment:
-
Originally posted by BwackNinja View PostAs 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.
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 😂
Leave a comment:
-
make: 233472 bytes
meson + ninja + py3-setuptools: 8105984 bytes
3300% increase in size.
Leave a comment:
Leave a comment: