Hi

On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé <berrange@redhat.com> wrote:

On Sat, Feb 05, 2022 at 12:17:08AM +0100, Kevin Kofler via devel wrote:
> Marc-André Lureau wrote:
> > Fwiw, given that the primary use case for a cross-toolchain is for
> > developer needs, I think it is reasonable to have only UCRT target in the
> > future.
> >
> > Projects releasing for Windows should probably natively build and test
> > their releases with Msys2, and they can do so for msvcrt targets.
>
> Well, with cross-MinGW and cross-NSIS, I can package software for Windows
> without ever touching a Windows machine. I have done so more than once
> already. I do not even have a Windows installation on which I can run Msys2.

Exactly, this is the precise reason why a group of us started
the Fedora mingw packaging effort all those years ago.

I have a Windows machine for testing / debugging on, but it is so
much simpler if we can do cross builds from Linux, as it means we
don't have to switch context between machines when developing.

Nowadays, with the built-in ssh server, git, msys2, meson, docker and CI..., developing for Windows is much easier than it was 10y ago!

For me, it's barely a context switch, sync the repo and run "meson test"  (or cmake) there. I haven't tried the shared folder yet. Testing the windows build is not something you can really do on Linux... So I will prefer a native build whenever possible.

Anyway, no need to convince me about the need for cross-compilers :) However, I regret that we have undermaintained and duplicated mingw*-pkg. I am looking at whether we can use msys2 packages instead (for developpers).

As noted in the mingw list thread, for me the objective of version parity between native and mingw packages of the current mingw-environment is a big selling point. My real-world experience reflects what others shared in this post, namely that by far most issues which pop up during testing are target independent, i.e. will affect both the native build as the cross-compiled build. It's true that version partiy is not 100% reflected in the current package state, but I still believe the overall state is pretty good, and personally I'd rather look at building cross and native packages from the same spec to reduce the maintenance burden. I know that there was a proposal in this direction some months ago, I'd like to start moving in this direction at least with packages where I maintain both the native and the cross packages.

Sandro