On Oct 4, 2005, at 10:46 AM, Stephen Langer wrote:
On Oct 3, 2005, at 3:15 PM, Bob Ippolito wrote:
On Oct 3, 2005, at 10:56 AM, Stephen Langer wrote:
Is it possible to create libBase portably with
possible to do it on Linux by subclassing build_ext.build_ext and
explicitly using self.compiler.compile() and
self.compiler.link_shared_lib() to build the shared library before
calling build_ext.build_ext.build_extensions(). But the same
thing on Mac OS X only creates libBase.so, whereas I need it to create libBase.dylib.
I don't know if this is possible, although I'd guess it is not.
That's too bad. Is there a reason for it? I'd volunteer to work on modifying distutils so that it can build a .dylib, but I am not an expert on library formats. I don't really know the difference between a .so and a .dylib, except that one of them works and the other doesn't. Can someone point me in the direction of a good reference on the topic?
The most portable way is to not build a libBase at all. Build a
Python extension that has all the functionality from libBase
available in it as a data structure with function pointers, and get
a reference to that from everything that depends on libBase
functionality. Take a look at what Numeric's C API does, for
Will such a scheme allow me to define a C++ base class in one module, and have other modules define derived classes? I want users to be able to define derived classes without having to recompile the whole program. I also want to be able to choose which parts of the program are loaded, so the base classes and some of the derived classes will be in one library, but other derived classes will be separate.
I don't know enough about C++ implementation details to answer that..
try it and see if it works. It would definitely work for anything C
or Objective-C based, but C++ is crazy so I don't know.