[vtk-developers] Re: VTK Python Installation [was: VTK 5.0 branch in mid-August]

[Prabhu Ramachandran]

>>>>> "Brad" == Brad King <brad.king at kitware.com> writes:

    >> If this does work on all unices then the chdir trick is a
    >> possibility, although I still think the Apple solution is
    >> cleaner.

    Brad> The two approaches are not mutually exclusive.  I like the
    Brad> Apple approach too.  The actual module that gets loaded can
    Brad> be put in the site-packages directory, but since it links to
    Brad> the vtk python shared libraries they must be found somehow.
    Brad> My solution uses the rpath/chdir trick to accomplish this
    Brad> part.  It has been tested on several unices and should work
    Brad> for any unix that supports rpath.  Note that OSX does not
    Brad> support rpath but does allow a path to be put in the soname
    Brad> field of a library, which can be used to approximate rpath
    Brad> behavior.

OK, but can these be relative paths like '.'.  My ideal goal would be
the following:

 1. Install the VTK shared libraries some standard place on linker's
    path (/usr/lib or PATH).

 2. Install the VTK-Python stuff in another standard place like
    site-packages/vtk.  The libvtk*Python.so's should go into this
    directory.  If the installed directory is not in site-packages
    users will need to just set PYTHONPATH.

So, in the best case like an RPM/deb install, the user needs to do
nothing.

If rpath='.' works on all unices and relative paths also work on OSX.
Then, we can consider using this for just the libvtk*Python.so's and
be done with it.  AFAIK if the libvtk*Python.so's were installed in
the same place as the vtk/__init__.py we don't need any chdir tricks
either.

    Brad> I thinks the real solution is to finally put the shared
    Brad> library version numbers on the VTK libraries and install
    Brad> them in lib/ instead of lib/vtk.  Then the system ld.so.conf

Yes, I did not want to open this can of worms.  IIRC, this request for
versioned libraries has come up several times in the past.  IIRC,
there were plans to have this supported for VTK 4.x.

    Brad> should find the libraries.  For users that install into
    Brad> another prefix it is their problem to get its lib/ directory
    Brad> in the shared library search path.  We could then use the
    Brad> rpath/chdir trick only when creating binary tarballs or CDs.

Yes, I think tricks are OK for developers not for the users who are
not likely to have 100 different VTK installs on their system.

So, I'd vote for versioned VTK libs.  I'd also like to reach a
consensus on what to do about the Python modules.

 1. Does rpath/soname work with '.' under all platforms supported?

 2. If the answer to 1 is yes, do we go with this or still go with the
    Apple solution?  If not I think we should just go for the Apple
    solution.

 3. How hard would it be to add version numbers for the VTK libraries?
    Should we wait till this happens?

Brad, can you please clarify on 1.  Thanks!

cheers,
prabhu