On 2021-11-01 10:27, Achim Gratz wrote:
Brian Inglis writes:
Perhaps someone could explain why Cygwin maintains, builds, and
distributes Mingw tools and libraries, instead of that being done by
the Mingw project(s) about which I know little?

MinGW is not a distribution, so there is no such source.

As we will be dropping Windows versions and 32 bit support in future
releases, should we also be looking at dropping the Mingw packages we
maintain, build, and distribute, but do not appear to use, except for
building other Mingw packages?

In general the MingW packages in Cygwin are used (or were planned to be
used) as dependencies for other stuff that Cygwin builds or uses, like
setup.exe or cross-compilation toolchains.  There are undoubtedly
instances where this is not the case or even never was, but those could
be dropped anytime if it presents too much of a burden.

Are they actually being used for anything, in this Cygwin project, or the associated Mingw or Wine projects, or are they holdovers from some earlier RedHat project? They appear to duplicate the Fedora packages, so who is using which package builds?

Supporting the two Mingw variations on packages sometimes takes as
much work as the Cygwin packages, as parts of the toolchains and
libraries may have different versions and dependencies.

I basically build, check, and distribute those, but know little about
using them to check they work, so no idea whether they work or not.

So?

I support packages I use, or libraries used by those packages, as I can dogfood them before release. I am uncomfortable that I can not do so to test the Mingw devel packages I upgrade with their Cygwin equivalents, and know so little about their potential uses.

I have had little success in getting the Mingw dual arch build process
working to any useful extent, and no response to questions about that,
which I may have buried at the end of my other verbiage on this list.

Not sure what you are talking about.  Anything MingW is always cross-compiled,
so if one architecture works, then the other does as well (modulo bugs
and differences in installed packages).

I mean the Mingw packages are sufficiently different from the Cygwin packages that they are effectively another different package, but requiring two separate cygport files. I try to maintain all cygport files in sync using gvimdiff to reduce the maintenance burden and increase similarities and synergies at the cost of some commenting out and readability.

The inherit mingw cygclass intended to allow Mingw packages to be built like Cygwin packages using the same cygport for both arches, and not require two additional cygport files, two git-cygwin-package repos, etc. It appears to work okay up to the compile but not install, package, etc. cygport stages.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Reply via email to