Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 07.02.22 10:29, Marc-André Lureau wrote:
Hi

On Mon, Feb 7, 2022 at 1:01 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux