[PyKDE] Dependency on sip.pyd

[Phil Thompson]

On Friday 10 November 2006 7:44 pm, Giovanni Bajo wrote:
> Phil Thompson wrote:
> >> What I would like to obtain is that modules generated by SIP do not
> >> depend on an external module (sip.pyd). This is technically possible
> >> of course, it's just that SIP was designed in a different way.
> >>
> >>> sip.pyd is a Python extension module - it is not a library and it is
> >>> not linked against.
> >>
> >> This is the current design, I'm asking to add an option to change
> >> this.
> >>
> >>> You can build it statically and have it built in
> >>> to your Python interpreter - same for PyQt (though I don't test
> >>> this). So you could create a project specific interpreter.
> >>
> >> To be clear, I'm not speaking of embedding sip.pyd in python.dll as a
> >> builtin module. I'm speaking of totally *removing* sip.pyd as a
> >> module, and just "put" all the necessary code within my own
> >> extension module created by SIP.
> >
> > ...just like SIP v0.1 used to work.
>
> You mean just like any other binding tool does? I don't see boost::python
> or SWIG generating a module which depends on another one. You even list the
> fact that generated modules are directly importable without a Python
> wrapper (as those generated by SWIG) as a feature. I don't see why making
> them not depend on an external module is not progress.

Progress, yes. Possible, yes. Worth the effort? I'm not convinced.

A genuine question (because I don't know the answer) - do Boost and SWIG 
support the wrapping of a C++ class hierarchy across multiple modules? Do 
they support the ability for somebody else to wrap 3rd party libraries that 
derive from the wrapped C++ library? That (to me anyway) is SIP's most 
important feature.

> > No, I'm not going to do that.
>
> Why?
>
> I explained real effective troubles which are caused by the current design.
> Binary dependency *is* a bad headache which seriously affects the usage of
> SIP, and its choice as a primary binding tool within a company. I would
> appreciate if you could explain your position.

The first versions of SIP generated all code in-line. The common code was 
broken out into a separate library/module (I think) when I wanted to separate 
PyQt and PyKDE. By "library/module" I mean that the SIP code was implemented 
as a separate Python extension module, but also linked against by the 
generated code. This was the design of SIP v3.

That design broke all the rules of Python extension modules. It also wouldn't 
work on MacOS (because modules and libraries are compiled with different 
flags). SIP v4 fixed those problems.

The sip module isn't just a "library" of code common to SIP generated modules. 
It handles the exporting of lots of code from (for example) PyQt to PyKDE or 
PyQwt without PyQt being aware of the existence of PyKDE, PyQwt etc. I'm sure 
it would be possible to implement that without a sip module, but the obvious 
(aka easiest) solution is to have a central module that acts as a broker for 
all the inter-module communications that are required.

If Boost and SWIG implement this without a central module then I bow to their 
superior architecture. If they don't support this functionality...then I 
don't bow. (I think the correct expression is that "I fart in your general 
direction".)

I appreciate your problem is real, but this solution isn't the right one.

Phil