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

[Brad King]

David Gobbi wrote:
> This sounds good.  If the default behaviour of VTK's cmake; make; make 
> install was to put versioned and rpath-free libraries into 
> /usr/local/lib, that would be wonderful.
> 
> 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.

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

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

-Brad