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