Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)

[Hoosier, Matt]

Hi Daniel,

Okay, makes sense that you don’t want to have to repeat the dependencies’ builds for every CI test. I’m not arguing that you should – it was just more a thought experiment to see whether riding Meson subprojects is a reasonable idea for establishing a development environment.

I get your point that that can become a deep rabbit hole. But it seems that you didn’t have any need to build LLVM and similar just to support the hand-built copy of Mesa that’s in the CI. Is there some reason why a deeper set of transitive dependencies would be needed using Meson subprojects than when building by hand? Seems like I could probably just mimic what you’ve done. Maybe your point is that the CI is a very constrained environment that’s known not to need ATI or llvmpipe, but a general developer situation with physical machines would?

-Matt

From: Daniel Stone <daniel at fooishbar.org>
Sent: Friday, June 7, 2024 10:17 AM
To: Hoosier, Matt <Matt.Hoosier at garmin.com>
Cc: Pekka Paalanen <pekka.paalanen at collabora.com>; Marius Vlad <marius.vlad at collabora.com>; wayland-devel at lists.freedesktop.org
Subject: Re: Ways to test Weston during development (Re: Full-motion zero-copy screen capture in Weston)

Hi Matt, On Fri, 7 Jun 2024 at 15: 30, Hoosier, Matt <Matt. Hoosier@ garmin. com> wrote: > Would Meson’s dependency wrapping capabilities be a viable solution here? I think that most of Weston’s dependencies that have aggressive version
jQcmQRYFpfptBannerStart
Hi Matt,



On Fri, 7 Jun 2024 at 15:30, Hoosier, Matt <Matt.Hoosier at garmin.com<mailto:Matt.Hoosier at garmin.com>> wrote:

> Would Meson’s dependency wrapping capabilities be a viable solution here? I think that most of Weston’s dependencies that have aggressive version requirements are themselves also Meson projects.

>

> The Weston CI configuration builds a bunch of its dependencies (Mesa, libdrm, libwayland …) manually. I wonder why Meson wrapping was not used for this?



We don't want to rebuild Mesa every time. We could've built it as a

subproject and cached it, but it didn't seem to offer much any

advantage over just installing it into the system.



We could probably add some subprojects, but you'd probably end up

pulling in more components as well - e.g. if you want to run Mesa with

its software renderer or the AMD drivers, you'll also need to use LLVM

- and at what point does your easy subproject build turn into, well, a

full distribution?



I guess one thing we could do is to jazz the CI build up a little so

it's easier to pull the OCI and run it inside a toolbox, as well as

reuse those scripts locally.



Cheers,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20240607/6e1b4c75/attachment-0001.htm>