[vtk-developers] Re: VTK Python Installation [was: VTK 5.0 branchin mid-August]
Andrew Maclean
a.maclean at cas.edu.au
Wed Aug 3 19:38:21 EDT 2005
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
More information about the vtk-developers
mailing list