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