Dropping various support in future releases - what about Mingw?

Dropping various support in future releases - what about Mingw?

[Brian Inglis]

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?

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?

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.

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.

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

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

[Jason Pyeron]

> -----Original Message-----
> From: Brian Inglis
> Sent: Sunday, October 31, 2021 11:23 AM
> 
> 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?
> 
> 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?
> 
> 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.
> 
> 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.

Kyle,

Thoughts?

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

--
Jason Pyeron  | Architect
PD Inc        | Certified SBA 8(a)
10 w 24th St  | Certified SBA HUBZone
Baltimore, MD | CAGE Code: 1WVR6
 
.mil: jason.j.pyeron.ctr@mail.mil
.com: jpyeron@pdinc.us
tel : 202-741-9397

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

[Achim Gratz]

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.

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


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

[Kyle Marek]

On 10/31/21 7:06 PM, Jason Pyeron wrote:
>> -----Original Message-----
>> From: Brian Inglis
>> Sent: Sunday, October 31, 2021 11:23 AM
>>
>> 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?
>>
>> 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?
>>
>> 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.
>>
>> 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.
> Kyle,
>
> Thoughts?

Being a GCC toolchain, MinGW *could* distribute binaries built with 
MinGW itself (such that they do not depend in Cygwin or MSYS). However, 
MinGW doesn't have a package manager that would allow developers to 
easily add development libraries besides the usual msvcrt symbol stubs 
and libstdc++ or whatever, so I wouldn't necessarily say that they 
*should* distribute binaries themselves.

On the 32-bit support issue: regardless of Cygwin dropping support for 
32-bit, and regardless of Cygwin's own use of MinGW to build setup.exe 
(as Achim pointed out), MinGW is used as a cross-compiler for developers 
to target 32-bit non-Cygwin platforms. There is value in Cygwin being 
useful on modern machines as a development environment to target older 
platforms, even if Cygwin itself won't run on older platforms. Obviously 
this might be a minority use case and Cygwin is a volunteer project, so 
it would be understandable if the 32-bit cross compiler packages went 
away due to a lack of volunteer interest. I hope this doesn't happen, 
because it is not really fun to compile our own cross-compilers.

I am not a Cygwin package maintainer, so I have no opinions regarding 
package maintenance.

-- 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Kyle Marek                        PD Inc. http://www.pdinc.us -
- Jr. Developer                     10 West 24th Street #100    -
- +1 (443) 269-1555 x361            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

[Brian Inglis]

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

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

[Achim Gratz]

Brian Inglis writes:
> 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?

It would help if you asked questions that are answerable.  I have no
idea what you refer to as "they" above.  As said before, there are
examples for everything; looking at a few of my own packages: GMP, MPFR
and ISL are needed for the MingW cross-compilation toolchain, ZStd for
setup, cfitsio I have no idea.

> They appear to duplicate the Fedora packages, so who is using which
> package builds?

For a start, have a look which packages require mingw64-* packages.  If
you want to drop a package that seems to be unused, just say so and if
it's still needed you will likely hear who is that customer.

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

You will never be able to fully vet each package if it has any
complexity, so you either get comforatble with the fact that often the
actual users will have more insight than you or (again) drop
maintenance.

> 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 think of the two cygport files as a wart and the separate Git archives is
another one even though Jon insists we need to keep it.

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

I've never started to use this cygclass as it seemed incomplete when it
was introduced, so I can't comment.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html