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
