On Jan 6, 2006, at 10:27 PM, Bob Ippolito wrote: > On Jan 6, 2006, at 6:55 PM, Stephen Langer wrote: >> On Jan 6, 2006, at 11:33 AM, Bob Ippolito wrote: >>> On Jan 6, 2006, at 8:19 AM, Phillip J. Eby wrote: >>>> >>>> The issue for the PyICU/PyLucene etc. use cases is that there >>>> are a whole >>>> bunch of SWIG wrappers for different extensions, but with a >>>> large common >>>> library for type mapping etc. The authors want a shared library >>>> for *their >>>> own code* that is used by multiple extensions. This is not >>>> separately >>>> distributed code. >>> >>> It'd be better if these projects just fixed themselves to do things >>> the "right" way, using a Python extension and a function table. >> >> Can you explain to me in more detail what the "right" way is? I >> have a large number of swig wrapper files for a large number of C+ >> + files. The program has a small number of core shared libraries >> that are always loaded, and a few that are optional. The shared >> library code is written in C++. Sometimes classes defined in the >> core libraries are used as base classes for classes defined in the >> optional libraries. All of this can be handled easily with shared >> libraries. How can it be done with function tables? > > Numeric, Numarray, pygame, PyObjC, etc. are good references for how > to export bits of C API as a function table. I don't use C++ > unless I have to, so I'm not familiar enough with it to say whether > or not it's going to cause problems given how you want to use it. > Maybe it's not possible without refactoring the optional library > code to work some other way.
Ok, I've looked at some of these examples. I haven't had the time to go through their mechanisms in detail, but it seems that under the hood they don't do anything terribly different from what swig does. I still don't see how they pertain to solving the shared library problem, and how doing things the "right" way makes shared libraries unnecessary. If extension A and extension B both require routine Z, and there's no python extension for routine Z, isn't the best solution to put Z in a shared library? I hope I'm not being dense here. We have lots of python extensions, all of which link to a relatively small number of shared libraries, and I'd like to understand why this setup is "wrong". -- Steve -- -- EMail: [EMAIL PROTECTED] Phone: (301) 975-5423 -- -- WWW: http://math.nist.gov/mcsd/Staff/SLanger/ Fax: (301) 990-4127 -- -- Mail: NIST; 100 Bureau Drive -- Stop 8910; Gaithersburg, Md 20899-8910 -- -- "I don't think this will work. That's why it's science." -- -- Naomi Langer, 17 Feb 2003 -- _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
