switch to muon: part 1.5

[apprehensions]

libinput and xf86-video-intel need testing.

[echawk]

Looks good so far, I'm testing the packages.

The first issue though is with gtk+3, the muon patch depends on the atk removal patches being applied, so that will need to be fixed, along with adding patch -p1 < 05-muon.patch be ran with the fribidi removal.

Also the build for libxkbcommon fails if you have valgrind installed.

Just finished building the rest of them, and it seems the only 2 with issues are gtk+3 & libxkbcommon. Thank you for the PR, and many thanks to @illiliti for working on muon.

[apprehensions]

Also the build for libxkbcommon fails if you have valgrind installed.

$ kiss s valgrind
ERROR 'valgrind' not found 

what is valgrind anyway?

The first issue though is with gtk+3

1 out of 4 hunks FAILED -- saving rejects to file gtk/meson.build.rej

is this what you mean?

[apprehensions]

i would also like to point out the last 2 packages that i couldn't convert to muon was mesa and freetype-harfbuzz - the latter being a muon bug, and mesa being because of LLVM.

[echawk]

Also the build for libxkbcommon fails if you have valgrind installed.

$ kiss s valgrind
ERROR 'valgrind' not found 

Here's a link to it: https://github.com/ehawkvu/kiss-personal/tree/master/utils/valgrind

what is valgrind anyway?

It's a suite of debugging tools - there's a callgraph generator, a memory leak checker, and some other tools.

The first issue though is with gtk+3

1 out of 4 hunks FAILED -- saving rejects to file gtk/meson.build.rej

is this what you mean?

Yes, that's what I get when running with GNU patch. Busybox patch also fails, but it fails with Hunk 2.

[eli-schwartz]

Is it sufficient to leave those packages using Meson for now, and move forward with migrating the packages that have thus far been successfully switched?

[apprehensions]

Yes, since I presume both are muon problems

[echawk]

libxkbcommon is fixed now, make sure to pull in those changes. That just leaves gtk+3 to be fixed or left for a later date.

[apprehensions]

btw @eli-schwartz i always wanted to ask, why do i see you specifically in muon-related issues or prs and stuff? dont you like do meson development n stuff

[apprehensions]

also @ehawkvu , am i allowed to update libsigc++ as part of this PR? cairomm will not compile without it. unless #93 takes place and it gets dropped

[eli-schwartz]

@wael444

Speaking with my Meson core developer hat on, I think it's amazing that muon exists, and I support its development and hang out in the muon development space as well in order to offer advice, insight into Meson design decisions, and the occasional patch to muon's own codebase.

I like to think that meson is a build system description language more than an implementation. The python implementation is really just a reference implementation and a way for me to drive improvements to the language.

That's why I'm also the person that committed updates to Meson's documentation FAQ to teach people about muon existing. The Meson FAQ also speaks about how Meson's language design was specifically intended from the beginning to be implementation language agnostic -- that's why we don't provide a python extension framework, for example.

So really, the better question is, if I'm such a fan of Meson, why wouldn't I support muon? Muon vindicates my belief in Meson's core design principles, and makes the meson build system more accessible to people in situations such as bootstrapping, resource constrained systems, etc. :D

[echawk]

also @ehawkvu , am i allowed to update libsigc++ as part of this PR? cairomm will not compile without it. unless #93 takes place and it gets dropped

I'm fine with you updating libsigc++.

[apprehensions]

esources is a pain in my ass

[echawk]

If you want to restrict this PR's scope to just things outside of community, I'm fine with that - I'm assuming that meson will still be around in some form while we convert the rest of the packages over.