[PyKDE] exported symbols - all or none?

[Gerard Vermeulen]

On Wed, 27 Apr 2005 14:40:09 -0400
Anthony Heading <aheading at jpmorgan.com> wrote:

> 
> On Wed, Apr 27, 2005 at 08:42:34AM +0100, Phil Thompson wrote:
> > And the bolted on code isn't called from Python?
> 
> It's not wrapped via SIP.
>
Why don't you compile and link your bolted-on code statically to your SIP
generated Python extension?  For instance PyQwt does that to import two
conflicting API's into the same SIP generated extensions.  But also to
be independent of system wide dynamic link libraries.

See
http://cvs.sourceforge.net/viewcvs.py/pyqwt/pyqwt3d/configure/configure.py?view=markup
for an example script (involves copying your bolted-on code amongst the
SIP generated files and patching the .sbf file, so that the Makefile
knows about your extra files).


> 
> > A function could be added to do what you want - but it would still require 
> > that you imported the modules that defined the classes you were interested 
> > in.
> 
> I don't understand that.  The sip module could theoretically broker any
> information between modules, no?   Even more simply, is it unreasonable
> to want to call  sipGetAPI("qt")?   From that, I could chase all
> the function pointers I need.
>
Yes, you could still link to them, but it is an annoyance on Unix/Linux
platforms.
> 
> > Python modules are not shared libraries that you should link against - they 
> > are more like plugins. On most platforms libraries and plugins are 
> > implemented identically. When I first designed SIP I didn't understand the 
> > distinction and used the generated module as both a shared library and a 
> > plugin - which meant that it didn't work on platforms that implemented them 
> > differently. SIP 4 corrected this design error.
> 
> Understand. But %Import'ing e.g. the qt module generates a lot of files, enough
> to extend the qt class hierararchy, and seems a lot of baggage just to get hold
> of some function pointers.
> 
> But if I understand now, there's an implicit rule that the only C++ code
> that can interact with a SIP module is in a derived module.   I'm not
> sure why that rule is imposed, because at a Python level any C++ code
> can call PyImport_ImportModule (just as sip_api_export_module is doing) 
> to access a module without any requirement to inherit from it.  And
> that's a different constraint from the plugin/library linker distinction.
> 
I think you can still do the SIP equivalent of PyImport_Module and use
the SIP generated headers for Qt (but you'd better be sure not to mix
different versions).

Gerard