[vtk-developers] VTK 5.0 branch in mid-August
Prabhu Ramachandran
prabhu_r at users.sf.net
Tue Aug 2 02:01:34 EDT 2005
>>>>> "Brad" == Brad King <brad.king at kitware.com> writes:
Brad> Prabhu Ramachandran wrote:
>> I had plans to make some small changes to the Python extension
>> modules. The idea is to use the Apple approach, i.e. build a
>> vtk*PythonD.so and install that along with the other VTK
>> libraries and then build a separate vtk*Python.so that links to
>> the vtk*PythonD.so. This makes it much easier to install
>> vtkpython. However, this might be too much of a change, so I
>> am willing to do this after 5.0 is released (maybe for 5.1).
Brad> Take a look at how we do this in ITK:
Unfortunately, I don't approve of this approach for the following
reasons:
1. AFAICT, this is a totally non-standard hack. I've never seen a
single Python package using os.chdir with a hard coded path to
import extension modules.
2. Using a hard coded path in a Python module and then relying on
that to import extension modules is an error prone approach that
will lead to lots of heartache. This approach seems OK from the
perspective of a VTK developer. Most folks however would not
enjoy, care for, or want to build VTK from sources. For these
folks binary installers are the only hope. Using a hard coded
path deep inside a Python module makes packaging such binaries a
pain. It also makes it impossible to make relocateable binaries.
Think of tarballs that bundle the VTK-Python modules. In order to
work for everyone, these will require the user fiddling with the
vtkbase.py (or whatever) and hardcode the location of the module.
Things are hard enough as they are.
3. Some folks (atleast Charl and I do) build standalone binaries of
our Python code along with VTK-Python. These will not work
anymore (without more hacks) with this approach due to the
non-standard nature of the hack.
OTOH, the Apple approach is simple and standard. Build
libvtk*PythonD.so's and install them in the same place the other VTK
shared libraries (or dll's) are installed. These libraries need to be
on the linkers path or on PATH (both are standard things that users,
packagers and admins know how to change). Then build the
libvtk*Python.so extension modules that link to the
libvtk*PythonD.so's. This is perfectly standard in the Python world.
These extension modules will be small so there is no significant space
overhead.
Thoughts?
cheers,
prabhu
More information about the vtk-developers
mailing list