[python-win32] Communicating symbols between extension modules

[Niki Spahiev]

Jack Jansen wrote:
> Greetings,
> as I'm finally going to put some work again into porting the QuickTime 
> package to Windows (at least: assuming no urgent matters turn up) I need 
> a bit of help.
> 
> The quicktime package will consist of a couple of extension modules and 
> some Python modules, all nicely wrapped up in a package. The problem is 
> that the extension modules need access to some symbols from other 
> extension modules (within the same package). Specifically, the O& object 
> encode/decode routines need to be available in other modules.
> 
> On the Mac this problem is solved through a file mactoolboxglue.c that 
> lives in the core python and which handles the indirection: a module 
> that needs Movie objects calls PyMovieObj_New from mactoolboxglue.c and 
> that routine has a pointer to the real conversion routine. If the 
> pointer is NULL it knows that it has to import the "_Qt" module, which 
> in its _Qtinit() routine will communicate the address of the real 
> _PyMovieObj_New routine to mactoolboxglue.c, after which things are tied 
> together.
> 
> As this solution relies on support in the core Python DLL it won't work 
> for QuickTime for Windows, so I need something else. I can think of 
> numerous ways to solve this, but I'm not sure which solutions would work 
> on Windows, and which one is best, so I'd like some thoughts on that, 
> please.
> 
> Here's a few ideas I have:
> - link all modules against a DLL that has the same function as 
> mactoolboxglue, and put that DLL in the package. This would work if the 
> extension modules would pick up this dll if it sat in the same 
> directory. Is this so?
> - the same, but put the DLL in /System/Win32 or somesuch, like 
> PyWinTypes does (or, at least, used to do when I last used PythonWin). I 
> don't like this solution much, though.
> - make the glue code a true python module, and import/export routine 
> pointers through cobjects.  Should work on any platform, but has the 
> disadvantage that it needs more magic in the C code.
> 
> Any thoughts?

IMO Numeric has the same problem and solution to it.

HTH
Niki Spahiev