* cygwin port of glib @ 2019-03-03 10:07 LRN 2019-03-05 14:07 ` E. Madison Bray 0 siblings, 1 reply; 6+ messages in thread From: LRN @ 2019-03-03 10:07 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cygwin port of glib 2019-03-03 10:07 cygwin port of glib LRN @ 2019-03-05 14:07 ` E. Madison Bray 2019-03-05 14:23 ` LRN 0 siblings, 1 reply; 6+ messages in thread From: E. Madison Bray @ 2019-03-05 14:07 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cygwin port of glib 2019-03-05 14:07 ` E. Madison Bray @ 2019-03-05 14:23 ` LRN 2019-04-03 12:16 ` LRN 0 siblings, 1 reply; 6+ messages in thread From: LRN @ 2019-03-05 14:23 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cygwin port of glib 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 0 siblings, 2 replies; 6+ messages in thread From: LRN @ 2019-04-03 12:16 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cygwin port of glib 2019-04-03 12:16 ` LRN @ 2019-04-11 11:51 ` LRN 2019-04-17 17:43 ` [Attn. Maintainer] glib2.0 LRN 1 sibling, 0 replies; 6+ messages in thread From: LRN @ 2019-04-11 11:51 UTC (permalink / raw) To: cygwin; +Cc: Yaakov Selkowitz [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Attn. Maintainer] glib2.0 2019-04-03 12:16 ` LRN 2019-04-11 11:51 ` LRN @ 2019-04-17 17:43 ` LRN 1 sibling, 0 replies; 6+ messages in thread From: LRN @ 2019-04-17 17:43 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-04-17 17:43 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-03 10:07 cygwin port of glib LRN 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
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).