Hi On Sat, Jan 29, 2022 at 1:10 AM Sandro Mani <manisan...@gmail.com> wrote: > > > On 28.01.22 21:50, Marc-André Lureau wrote: > > Hi > > > > On Sat, Jan 29, 2022 at 12:27 AM Sandro Mani <manisan...@gmail.com> wrote: > >> > >>> Interesting question, it really depends on our users I imagine. > >>> > >>> Since Windows recommends ucrt since Windows 10 (2015) and you can ship > >>> UCRT for earlier versions up to Vista, there are very few reasons you > >>> would want to keep msvcrt. Notably, wine may need msvcrt binaries. > >>> However, if this is the only case, we probably don't want to keep > >>> maintaining and distributing all the msvcrt binaries with Fedora. > >>> > >>> My recommendation going forward (past f37 and ucrt toolchain > >>> introduction probably, unless we all agree?) would be to remove > >>> mingw32/64 libraries, but keep the various toolchains. This way, users > >>> who still want to target msvcrt can rebuild their dependencies > >>> themself relatively easily. > >> This is what I was kinda also thinking about. The one thing that scares > >> me TBH is having to go through rename-rereview of all mingw -> ucrt > >> packages. I wonder if one could handle it like > > Why renaming? what I propose is to add ucrt64-* libraries. > > > > For example, we have mingw32-zlib & mingw64-zlib today. We would have > > to add a third ucrt64-zlib. > > > > It's tedious, but we don't have to do it all in one go, we can add it over > > time. > > > > And with the simple template system I propose (until RPM provides > > something) it is easier to adapt, it avoids having to repeat things. > Wait I think I got confused by the environments overview in [1], which I > read as ucrt being a separate thing than mingw, but it's just mingw with > the different runtime right? So to be precise, the one package should be > called say mingw64-msvc-zlib while the other mingw64-ucrt-zlib?
Yes, it's mingw with a different target runtime. Until ucrt, the target was only x86/x86-64 msvcrt, so mingw32/mingw64 prefix was used. I propose to add the ucrt64 prefix for the MinGW UCRT64 x86-64 Fedora packages. To be pedantic, we should use something like "mingw-w64-ucrt-x86_64" as package prefix I guess. ucrt64 is a reasonable short form. That's also what msys2 picked for their environment (MSYSTEM) and prefix (/ucrt64) So it's not about renaming mingw64-zlib to mingw64-msvc-zlib, and introducing mingw64-ucrt-zlib. It's only about adding ucrt64-zlib (progressively, package by package as needed, over time) > >> - ask FESCO to rename without re-rereview all mingw32/64-* packages to > >> win32/64-* (or whatever generic windows prefix), leaving the runtime out > >> of the package name > >> - when the time comes, change the runtime and just recompile the entire > >> mingw/win package set > > That won't work. One reason you need a transition period is also > > because ucrt may introduce regressions in your package that you may > > have to work on.. I have fixed a few ucrt-related issues in glib > > (among others https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2449) > Yes indeed > >> I guess this would add the challange of keeping the packages in sync > >> with the corresponding native version (which is already quite a > >> challenge inside the distro actually). > > Fedora would no longer ship any library or windows binaries (almost), > > only the cross toolchain. > > > > You would simply run "msys2-pacman -S foopkg" and get either the same > > package distributed for Windows installed somehow on your distro > > (perhaps even under $HOME), or a side msys2 project could cross-build > > them package for your target linux distro (if that's necessary, but I > > think we could eventually get the same windows packages). For the vast > > majority of packages, that approach should work. > > > > The other approach is to simply vendor and cross-build your > > dependencies with your project (like meson wrap, rust etc are doing). > > > > The required bits are only the cross-toolchains then. > So what was on my mind here is that one of the attractiveness of the > current mingw environment is that (for a large part) you can develop the > application on your host system, and then cross-compile the builds for > windows, having a high confidence that the cross-compiled application > will have the same library versions as the ones you developed and tested > with natively. And having them pre-packaged clearly is a huge time-saver. That's a reasonable model. But how many Windows projects out there are tight to the Fedora release lifecycle? A serious Windows project that needs mingw is probably built and tested on Windows, probably using msys2 or with a custom solution. MinGW cross-compilation on Fedora is mostly for Linux developer convenience, and other more marginal requirements. _______________________________________________ mingw mailing list -- mingw@lists.fedoraproject.org To unsubscribe send an email to mingw-le...@lists.fedoraproject.org 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/mingw@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
