[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:

    Brad> David Gobbi wrote:
    >> I have spent a lot of time trying to help users who do "make
    >> install" and then get into trouble because the rpaths of the
    >> installed libraries point back to the source tree that they are
    >> monkeying with.  In fact I've been bitten by this several
    >> times, myself.  It seems that LD_LIBRARY_PATH is a better
    >> approach than rpath for running things from the source tree,
    >> and it would be easy to set LD_LIBRARY_PATH (or its equivalent
    >> depending on the flavor of UNIX) from a front-end script.

    Brad> That would mean setting CMAKE_SKIP_RPATH in the VTK CMake
    Brad> code.  Unfortunately then we will get lots of questions from
    Brad> users trying to run things from the build tree, and we will
    Brad> have to explain how to set LD_LIBRARY_PATH.  I keep so man
    Brad> VTK build trees around that it would be impossible to
    Brad> remember which shell has which current LD_LIBRARY_PATH
    Brad> setting.  This is why we've been using rpath in the build
    Brad> tree.

Well, I think this is the wrong approach.  If someone is smart enough
to build VTK from sources and be able to use that, they surely are
smart enough to set a few paths or write a few scripts to help them
with their paths.  Using rpath just confuses things because very few
(if any) libraries use rpath.  Under Unix I'd say, dump rpath, use
LD_LIBRARY_PATH and have a shell script that lets you switch the
version depending on which build you need to test.  

For *users* of VTK/VTK-Python, install libs into /usr/lib (or
$prefix), install Python modules in
$prefix/python-<version>/site-packages/vtk.  Use VTK/VTK-Python.  End
of story.

    Brad> Recently for ParaView I created the KWSys "SharedForward"
    Brad> feature.  The real executable target "paraview" is renamed
    Brad> to "paraview-real" and a small C-only stand-alone executable
    Brad> called "paraview" is created using SharedForward.h.  This
    Brad> small executable knows how to set LD_LIBRARY_PATH properly
    Brad> and then calls "exec" to load "paraview-real".  In this way
    Brad> ParaView can use shared libraries but run from the build
    Brad> tree or install tree in any location without needing rpath.
    Brad> We could consider using this feature for VTK too.

It does not help.  AFAIK, most users of vtk-python don't use the
vtkpython executable and use the vanilla Python interpreter.  I think
that makes sense.  For an application like ParaView the approach you
take sounds good but not for VTK.

I think we need the simplest solution that would possibly work.  This
precludes the possibility of using a special interpreter, rpath or
chdir hacks.  In reality we end up with these various "hacks" for the
simple reason that we haven't bitten that bullet and versioned the VTK
libraries.  I think we need a good resolution of this mess before we
release 5.0.

cheers,
prabhu