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

[Andrew Maclean]

When you resolve all this remember to ensure that the python install for
Win32 works OK! 

E.g currently I have a path pointing to where the VTK dlls and exes are
namely PATH=C:\Program Files\VTK\bin;

Then I have a PYTHONPATH statement:
PYTHONPATH=C:\Program Files\VTK\bin;C:\Program
Files\VTK\lib\vtk;C:\vtk\VTK\Wrapping\Python;C:\vtk\VTK\Wrapping\Python\vtk;

The statement C:\Program Files\VTK\lib\vtk; is needed only if python is used
to run the scripts because the dll's are in C:\Program Files\VTK\lib\vtk;
instead of C:\Program Files\VTK\bin;

My observation (for Windows) is that it would be nice to get the all the
dlls and wrapping (possibly as subdirs) stuff into where the install occurs
e.g C:\Program Files\VTK\bin; This would greatly simplify paths.

The rationale hers is to keep a known good build in C:\Program Files\VTK and
only install into this directory when happy with the current CVS build. This
is the technique I use under Linux. Also when you release version 5.0 it
should make installation easier (I think).


Andrew



-----Original Message-----
From: vtk-developers-bounces+a.maclean=cas.edu.au at vtk.org
[mailto:vtk-developers-bounces+a.maclean=cas.edu.au at vtk.org] On Behalf Of
David Gobbi
Sent: Thursday, 4 August 2005 05:55
To: Brad King
Cc: vtk-developers at vtk.org; Charl P. Botha; Bill Hoffman; Prabhu
Ramachandran
Subject: Re: [vtk-developers] Re: VTK Python Installation [was: VTK 5.0
branchin mid-August]

Brad King wrote:

> 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.

Yes, since I use CMAKE_SKIP_RPATH I end up with tons of little .sh 
scripts that set LD_LIBRARY_PATH for different source trees, so I 
understand the utility of rpath in this circumstance.  But having an 
rpath to the source tree really messes people up after they do a make 
install or move their libraries around.

> 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.

For unix applications that I ship to customers, I just use a shell 
script as the front end and that works fine.  On Windows I sometimes use 
a .bat file and those just don't measure up, even with a fancy icon.  A 
front end written in C sounds like a good, unified approach.

 - David


_______________________________________________
vtk-developers mailing list
vtk-developers at vtk.org
http://www.vtk.org/mailman/listinfo/vtk-developers