cygwin port of glib

cygwin port of glib

[LRN]

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

Re: cygwin port of glib

[E. Madison Bray]

On Sun, Mar 3, 2019 at 11:07 AM LRN wrote:
>
> 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.

Hi,

While I'm not often as eager to "pass the buck" as many open source
contributors are (though I certainly understand the impulse), but in
this case I would suggest that, if you care enough to do it, you
should offer to upstream that they accept some/all of those patches,
as in most cases they may not even be aware it exists. My guess is
that whoever is maintaining the glib package for Cygwin either doesn't
know glib well enough to be able to advocate effectively for those
patches, or doesn't care enough to.

If they're clean, worthwhile patches then I absolutely think you
should get them integrated upstream if at all possible--that's almost
always preferable.  But be warned, it can be a significant time-suck
just to get patches upstream, even on projects that look ostensibly
like they support Cygwin.  From personal experience, I have been
trying to get Cygwin fixes to Python upstream and some of them have
taken *years* to get and multiple rewrites over time, despite being
seemingly simple and uncontroversial.

It's just the nature of working with lots and lots of projects that
have other concerns :(

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: cygwin port of glib

[LRN]

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

On 05.03.2019 17:07, E. Madison Bray wrote:
> On Sun, Mar 3, 2019 at 11:07 AM LRN wrote:
>>
>> 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)?
>>
> but in
> this case I would suggest that, if you care enough to do it, you
> should offer to upstream that they accept some/all of those patches,
> as in most cases they may not even be aware it exists. My guess is
> that whoever is maintaining the glib package for Cygwin

That would probably be Yaakov Selkowitz[0].

> either doesn't
> know glib well enough to be able to advocate effectively for those
> patches, or doesn't care enough to.
> 
> If they're clean, worthwhile patches then I absolutely think you
> should get them integrated upstream if at all possible--that's almost
> always preferable.

Okay, i'll see what i can do.

[0]: https://github.com/cygwinports/glib2.0/commits/master


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

Re: cygwin port of glib

[LRN]

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

On 05.03.2019 17:23, LRN wrote:
> On 05.03.2019 17:07, E. Madison Bray wrote:
>>
>> If they're clean, worthwhile patches then I absolutely think you
>> should get them integrated upstream if at all possible--that's almost
>> always preferable.
> 
> Okay, i'll see what i can do.
> 

Made some progress, but i would benefit from some input on a few things.

1) This[0] cygwinports commit and a related gnulib[1] commit. Which version of
cygwin (CYGWIN_VERSION_API_MINOR) corresponds to 1.7 (is the 1.7 number even
correct?). As a less-intrusive fix, i can switch
#ifdef __CYGWIN__
to
#if defined(__CYGWIN) && (!defined (CYGWIN_VERSION_API_MINOR) ||
CYGWIN_VERSION_API_MINOR < somevalue)


2) This[2] cygwinports commit. I don't quite get what the author means. Does he
mean that returning a path that looks like "//etc" from parsing a URI
"file:////etc" is correct? Or the opposite, that it should return "/etc" ? The
commit seems to be saying one thing, while the code does something else.


[0]:
https://github.com/cygwinports/glib2.0/commit/b61abed9554ab813ed358ea5bad648987573772e#diff-2d64c930085856723abe9a40105389abR256

[1]:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/localcharset.c?id=9f5ab735f030faf651961d55ce3b849dd56dcff3

[2]:
https://github.com/cygwinports/glib2.0/commit/40ca93c8ae81e7a05ec098246b43ce74e157ebd6#diff-c86c0d1edc7cdc043b8b01ee6e526817


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

Re: cygwin port of glib

[LRN]

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

On 03.04.2019 15:16, LRN wrote:
> On 05.03.2019 17:23, LRN wrote:
>> On 05.03.2019 17:07, E. Madison Bray wrote:
>>>
>>> If they're clean, worthwhile patches then I absolutely think you
>>> should get them integrated upstream if at all possible--that's almost
>>> always preferable.
>>
>> Okay, i'll see what i can do.
>>
> 
> Made some progress, but i would benefit from some input on a few things.
> 
> 1) This[0] cygwinports commit and a related gnulib[1] commit. Which version of
> cygwin (CYGWIN_VERSION_API_MINOR) corresponds to 1.7 (is the 1.7 number even
> correct?). As a less-intrusive fix, i can switch
> #ifdef __CYGWIN__
> to
> #if defined(__CYGWIN) && (!defined (CYGWIN_VERSION_API_MINOR) ||
> CYGWIN_VERSION_API_MINOR < somevalue)
> 
> 
> 2) This[2] cygwinports commit. I don't quite get what the author means. Does he
> mean that returning a path that looks like "//etc" from parsing a URI
> "file:////etc" is correct? Or the opposite, that it should return "/etc" ? The
> commit seems to be saying one thing, while the code does something else.
> 
> 
> [0]:
> https://github.com/cygwinports/glib2.0/commit/b61abed9554ab813ed358ea5bad648987573772e#diff-2d64c930085856723abe9a40105389abR256
> 
> [1]:
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/localcharset.c?id=9f5ab735f030faf651961d55ce3b849dd56dcff3
> 
> [2]:
> https://github.com/cygwinports/glib2.0/commit/40ca93c8ae81e7a05ec098246b43ce74e157ebd6#diff-c86c0d1edc7cdc043b8b01ee6e526817
> 

Hello? Anybody?


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

[Attn. Maintainer] glib2.0

[LRN]

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

On 03.04.2019 15:16, LRN wrote:
> On 05.03.2019 17:23, LRN wrote:
>> On 05.03.2019 17:07, E. Madison Bray wrote:
>>>
>>> If they're clean, worthwhile patches then I absolutely think you
>>> should get them integrated upstream if at all possible--that's almost
>>> always preferable.
>>
>> Okay, i'll see what i can do.
>>
> 
> Made some progress, but i would benefit from some input on a few things.
> 
> 1) This[0] cygwinports commit and a related gnulib[1] commit. Which version of
> cygwin (CYGWIN_VERSION_API_MINOR) corresponds to 1.7 (is the 1.7 number even
> correct?). As a less-intrusive fix, i can switch
> #ifdef __CYGWIN__
> to
> #if defined(__CYGWIN) && (!defined (CYGWIN_VERSION_API_MINOR) ||
> CYGWIN_VERSION_API_MINOR < somevalue)
> 
> 
> 2) This[2] cygwinports commit. I don't quite get what the author means. Does he
> mean that returning a path that looks like "//etc" from parsing a URI
> "file:////etc" is correct? Or the opposite, that it should return "/etc" ? The
> commit seems to be saying one thing, while the code does something else.
> 
> 
> [0]:
> https://github.com/cygwinports/glib2.0/commit/b61abed9554ab813ed358ea5bad648987573772e#diff-2d64c930085856723abe9a40105389abR256
> 
> [1]:
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/localcharset.c?id=9f5ab735f030faf651961d55ce3b849dd56dcff3
> 
> [2]:
> https://github.com/cygwinports/glib2.0/commit/40ca93c8ae81e7a05ec098246b43ce74e157ebd6#diff-c86c0d1edc7cdc043b8b01ee6e526817
> 

Added the "[Attn. Maintainer] glib2.0" tag to the subject, as suggested in a
different thread.


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