[vtk-developers] Re: VTK Python Installation [was: VTK 5.0 branch in mid-August]
Prabhu Ramachandran
prabhu_r at users.sf.net
Tue Aug 2 12:23:50 EDT 2005
>>>>> "Brad" == Brad King <brad.king at kitware.com> writes:
Brad> Prabhu Ramachandran wrote:
>> Still a hack, still needs hard coded paths.
Brad> Where are you guys seeing a hard-coded path in the itkbase
Brad> design? The whole point of it is to allow the binary to be
Brad> distributed and executed from anywhere. When I first wrote
Brad> it I put it on the ITK 1.6 CD and python scripts could be
Brad> executed by drag-and-drop onto the executable on the CD in
Brad> whatever drive it was sitting or in whatever path to which
Brad> the user had copied it.
Brad> The installed version of itkbase.py gets this package
Brad> directory:
Brad> SET(ITK_CSWIG_PACKAGE_DIR "os.path.dirname(selfpath)")
Hmm, I thought ITK_CSWIG_PACKAGE_DIR was a hard-coded path (I don't
use ITK). Why do you need this defined at all then? Why not have
this in itkbase.py:
pkgdir = os.path.dirname(selfpath)
To get this working with McMillan's installer will require a little
more work because __file__ is not available when the import hooks are
used. I suspect this is what Charl was referring to. However, it is
possible to work around this.
Brad> This allows it to compute the location of the rest of the
Brad> python wrappers wherever it may be. Then you just have to
Brad> build with CMAKE_SKIP_RPATH set to ON and the installation
Brad> will have no reference to the original build tree.
Under *nix, does this require that rpath be set with '.' in the rpath?
Will the os.chdir approach work at all if CMAKE_SKIP_RPATH is ON?
If it does depend on rpath then, this is not acceptable.
>> 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.
Brad> The itkbase design allows a binary to be extracted from a
Brad> tarball and executed out-of-the box without setting any PATH
Brad> or LD_LIBRARY_PATH. I do not see how the Apple design
Brad> addresses this. When the .so is loaded how does it find its
Brad> ...D.dylib libraries?
I just read David's response and he expresses my concern a lot better.
[...]
Brad> Not with the itkbase.py design. It requires only PYTHONPATH
Brad> to be set.
Brad> With my suggestion for stub packages in site-packages then
Brad> you don't
Brad> even need to set anything.
>From what I understand the os.chdir() trick works because of either
rpath or a hard-coded path. If I am wrong then this is worth
considering.
>> BTW, since VTK-5.0 is anyways backwards incompatible in many
>> ways, how about removing the backwards compatibility layer of
>> vtkpython.py, vtkpythontk.py, vtkRenderWidget.py, etc.?
Brad> That sounds good to me.
OK. Thanks!
cheers,
prabhu
More information about the vtk-developers
mailing list