Re: Dropping various support in future releases - what about Mingw?

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

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.]