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 <dan...@fooishbar.org> Sent: Friday, June 7, 2024 10:17 AM To: Hoosier, Matt <matt.hoos...@garmin.com> Cc: Pekka Paalanen <pekka.paala...@collabora.com>; Marius Vlad <marius.v...@collabora.com>; wayland-devel@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.hoos...@garmin.com<mailto:matt.hoos...@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
