Sean Paul <sean@xxxxxxxxxx> writes: > On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote: >> Hi all, >> >> This is just to collect feedback on this idea, and see whether the >> overall dri-devel community stands on all this. I think the past few >> cross-vendor uapi extensions all came with igts attached, and >> personally I think there's lots of value in having them: A >> cross-vendor interface isn't useful if every driver implements it >> slightly differently. >> >> I think there's 2 questions here: >> >> - Do we want to make such testcases mandatory? >> > > Yes, more testing == better code. > > >> - If yes, are we there yet, or is there something crucially missing >> still? > > In my experience, no. Last week while trying to replicate an intel-gfx CI > failure, I tried compiling igt for one of my (intel) chromebooks. It seems like > cross-compilation (or, in my case, just specifying > prefix/ld_library_path/sbin_path) is broken on igt. If we want to impose > restrictions across the entire subsystem, we need to make sure that everyone can > build and deploy igt easily. > > I managed to hack around everything and get it working, but I still haven't > tried switching out the toolchain. Once we have some GitLab CI to validate > cross-compilation, then we can consider making IGT mandatory. > > It's possible that I'm just a meson n00b and didn't use the right incantation, > so maybe it already works, but then we need better documentation. > > I've pasted my horrible hacks below, I also didn't have libunwind, so removed > its usage. I've also had to cut out libunwind for cross-compiling on many occasions. Worst library.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
