On Mon, Feb 07, 2022 at 10:50:00AM +0100, Sandro Mani wrote:
On 07.02.22 10:29, Marc-André Lureau wrote:
> Hi
>
> On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé <berrange(a)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.
Yes, I proposed that last year. I was supposed to move it forward by
providing a copr repo illustrating it in real world, but I'm afraid
I got side tracked.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|