public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: LRN <lrn1986@gmail.com>
To: cygwin@cygwin.com
Subject: cygwin port of glib
Date: Sun, 03 Mar 2019 10:07:00 -0000	[thread overview]
Message-ID: <dddf240b-0569-1e28-2e53-a5c833e12644@gmail.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1203 bytes --]

Looking at cygwin glib source package, i see a lot of downstream patches
applied to glib over the years (there are no dates, but the versions range from
2.34.3 to 2.50 - that might be as early as 2012 and as late as 2017) to make it
work correctly on cygwin.

Why are these not upstream (considering the fact that glib does have some
cygwin-specific code - clearly it's not because glib doesn't *want* cygwin
compatibility)?

Alternatively, since some of these patches *remove* cygwin-specific code from
glib (as, apparently, it was aimed at old versions of cygwin), why not ask glib
maintainers to remove cygwin support completely (which might simplify the
porting process, since cygwin glib maintainers won't have to guess which parts
of cygwin-specific code in glib are in working order, and which are not)? Also,
since cygwin masquerades as a linux-flavoured POSIX platform, a more correct
approach for glib might be to perform appropriate configure-time checks and
then use their results to decide which code to compile, instead of blindly
trusting that a particular piece of code will work on
bsd/linux/cygwin/whatever. That would remove the need for some of those patches.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

             reply	other threads:[~2019-03-03 10:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-03 10:07 LRN [this message]
2019-03-05 14:07 ` E. Madison Bray
2019-03-05 14:23   ` LRN
2019-04-03 12:16     ` LRN
2019-04-11 11:51       ` LRN
2019-04-17 17:43       ` [Attn. Maintainer] glib2.0 LRN

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=dddf240b-0569-1e28-2e53-a5c833e12644@gmail.com \
    --to=lrn1986@gmail.com \
    --cc=cygwin@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).