Hi On Wed, Jul 26, 2023 at 10:21 PM Thomas Huth <th...@redhat.com> wrote: > > On 26/07/2023 18.19, Daniel P. Berrangé wrote: > > Although they share a common parent, the two msys jobs still have > > massive duplication in their script definitions that can easily be > > collapsed. > > > > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com> > > --- > > .gitlab-ci.d/windows.yml | 132 +++++++++++++++------------------------ > > 1 file changed, 49 insertions(+), 83 deletions(-) > > We originally had different sets of packages in the 32-bit and 64-bit jobs, > to distribute the load between the two jobs ... but it got unified in commit > 14547e0877f3522. Now considering that we are facing timeouts again, we > should maybe rather revert that commit instead of unifying the lists forever? > > Anyway, before we unify the compiler package name suffix between the two > jobs, I really would like to see whether the mingw Clang builds QEMU faster > in the 64-bit job ... but so far I failed to convince meson to accept the > Clang from the mingw package ... does anybody know how to use Clang with > MSYS2 properly?
I checked it this week (because of bug #1782), and it compiled successfully. Although I think we may have some issues with clang on windows, as it doesn't pack struct the expected way. See also: https://discourse.llvm.org/t/how-to-undo-the-effect-of-mms-bitfields/72271. It may be a good idea to add some extra static checks about our packed struct padding expectations.. Eh, it didn't feel much faster to compile with clang :)
