Hi
On Sat, Jan 29, 2022 at 1:10 AM Sandro Mani manisandro@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 manisandro@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.