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?
- 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.
[1] https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt
_______________________________________________
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
