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. > 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. -- Giovanni Bajo _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde