[Jason Tishler]
> The attached will obviate need for patches like the following forever:
>
>
> http://sf.net/tracker/?func=detail&aid=676837&group_id=5470&atid=305470
>
> http://sf.net/tracker/?func=detail&aid=676839&group_id=5470&atid=305470
I'll note at the start that these two specific patches are just changing
PyObject_HEAD_INIT(&PyType_Type)
to
PyObject_HEAD_INIT(NULL)
in PyTypeObject definitions. That's a common thing throughout the code
base, although Cygwin seems to need it where no other systems do.
> Unfortunately, this is a slippery slope. Unlike auto-importing
> functions which has been around for a while, auto-importing data is
> very new (and kind of scary). Additionally, it requires a special
> linker option, --enable-runtime-pseudo-reloc, to work in all cases.
> Hence, Cygwin Python shared extensions and embedded interpreters will
> need to modify their build process unless they are using distutils.
>
> I'm looking for advice. Should I use the latest, greatest Cygwin
> functionality that makes building as similar as possible to Unix? Most
> likely at the expense of breaking some dependent packages. Or, are
> patches like the above considered acceptable and the preferred way to
> go?
Those specific patches are acceptable <wink>. Whether they're desirable has
partly to do with how you weigh the tradeoffs, and partly with that you'll
have to continue making such patches for so long as Cygwin has this unique
behavior (you can try to explain when it's needed, but it's not going to
sink in for people on other platforms).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4