public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: cygwin-apps@cygwin.com
Subject: Re: Dropping various support in future releases - what about Mingw?
Date: Mon, 01 Nov 2021 17:27:58 +0100	[thread overview]
Message-ID: <87y267zvqp.fsf@Rainer.invalid> (raw)
In-Reply-To: <d4f33cdb-08fc-ae12-b0cd-f60f0d2a12a8@SystematicSw.ab.ca> (Brian Inglis's message of "Sun, 31 Oct 2021 09:23:00 -0600")

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

  parent reply	other threads:[~2021-11-01 16:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-31 15:23 Brian Inglis
2021-10-31 23:06 ` Jason Pyeron
2021-11-01 17:33   ` Kyle Marek
2021-11-01 16:27 ` Achim Gratz [this message]
2021-11-01 18:47   ` Brian Inglis
2021-11-01 19:33     ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y267zvqp.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).