[Patches] Extension building on Win32 using Gnu C
Greg Ward
gward@mems-exchange.org
Wed, 7 Jun 2000 10:27:24 -0400
On 02 June 2000, Rene Liebscher said:
> I want to provide a patch which makes it possible
> to use the Gnu Win32 compilers (cygwin and mingw32)
> to build extensions.
Thanks! Comments follow.
> --- python.patched/dist/src/Include/Python.h Tue May 30 10:24:40 2000
[...]
> + /* The next are used by the Gnu C-compilers on Win32, for all others
> + they will be defined as empty */
> + /* Definition of every type, variables of which may be imported from DLL,
> + must be wrapped in DL_CLASSIMPORT_BEG/DL_CLASSIMPORT_END brackets */
> + #ifndef DL_CLASSIMPORT_BEG
> + #define DL_CLASSIMPORT_BEG
> + #endif
> + #ifndef DL_CLASSIMPORT_END
> + #define DL_CLASSIMPORT_END
> + #endif
OK, that seems simple enough.
> --- python.patched/dist/src/Include/object.h Tue May 30 10:34:33 2000
[...]
> --- 107,120 ----
> PyObject_HEAD \
> int ob_size; /* Number of items in variable part */
>
> ! typedef DL_CLASSIMPORT_BEG struct _object {
> PyObject_HEAD
> ! } DL_CLASSIMPORT_END PyObject;
>
>
> + typedef DL_CLASSIMPORT_BEG struct {
> + PyObject_VAR_HEAD
> + } DL_CLASSIMPORT_END PyVarObject;
This strikes me as really weird style. Do those macros really *have* to
be wormed into the typedefs in that way? Isn't there a cleaner way to
do it?
And do these macros have to be used in extensions as well? Eg. if foo.c
supplies an extension foo, so is compiled/linked to foo.pyd (a DLL in
disguise), do I have to scatter foo.c with DL_CLASSIMPORT_{BEG,END} tags
to make it compile with Cygwin?
Looks like the rest of the patch is just shoving
DL_CLASSIMPORT_{BEG,END} down Python.h's throat, and then a simple
addition to config.h. Except for the extreme uglitude of those
CLASSIMPORT macros, it seems straightforward enough.
Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange / CNRI voice: +1-703-262-5376
Reston, Virginia, USA fax: +1-703-262-5367