[vtkusers] VTK on Tcl 8.6 and with re-locatable TCL files, and more

[Sebastien BARRE]

At 10/17/2008 02:03 PM, Adam Williamson wrote:

Hi Adam,
Thanks for the feedback

>Actually making it work with Tcl 8.6 is not that hard. I had to add the
>necessary headers from Tcl/Tk 8.6 to Utilities/TclTk/internals . Then
>the only remaining issue is a few uses of the deprecated
>intern->result , which I filed as
>http://www.vtk.org/Bug/view.php?id=7822 .

I just fixed that one, thanks.

I built Tck/Tk 8.6 on Win32 (a pain, as usual), fixed the 
interp->result problems and added the missing Tk 8.6 headers and 
resources to Utilities/TclTk. I built KWWidgets against it for test, 
and it behaves as usual.

However, we won't/can't add your other changes to VTK, sorry.

As a rule of thumb, we try not to "spill over" the whole filesystem, 
by keeping all VTK-related files inside the same installation dir.
To run Tcl scripts people are suggested to use VTK's own Tcl shell, 
i.e. vtk.exe. If somebody needs another shell, we assume he/she is 
"experienced" enough to simply set the LD_LIBRARY_PATH and TCLLIBPATH 
accordingly; this is documented in the FAQ if I recall.

Several VTK versions should be able to co-exist together, and this is 
much easier and user-friendly to have them self-contained in their 
own installation tree than mixing them all over. Granted, Linux and 
its various package managers support different versions of the same 
software, but different distributions enforce different file 
structure: there is no reason to pick one over the other. we also 
need to be somehow consistent across all our platforms (Unix, Win32, 
MacOSX, etc); VTK is such a large system, and we bundle so many 
third-party libraries that we recommend installing in a "vtk" subdir, 
not in /usr.

We can't make changes to accommodate a single distribution 
(Fedora/Mandriva) which decided to force its own Tcl/Tk to look at a 
specific place; a fix already exists which is configuring your 
TCLLIBPATH to point at third-party Tcl packages (I assume they didn't 
break *that*). Furthermore, your changes are very extensive are were 
not tested on Win32 or MacOSX platforms.

Thanks

Quick answers to some of your questions though:

>VTK_INSTALL_LIB_DIR seems to lose the prefix, so you get 
>/lib/vtk-5.2 , not /usr/lib/vtk-5.2 .

Yes, this is definitely on purpose, all VTK_INSTALL_*_DIR are 
specified relative to the CMAKE_INSTALL_PREFIX variable, and should 
not be hard-coded.

>That patch also does something else useful: it makes it look for
>         libvtkFOO.so.5.2
>rather than
>         libvtkFOO.so
>on Mandriva (and probably other distributions), the unversioned .so
>files usually go in -devel packages.

We can't change that behavior either for backward compatibility reasons.
Libraries are indeed versioned already, (you should have in your 
build tree something like libvtkCommon.so, symlink to 
libvtkCommon.so.5.2, symlink to libvtkCommon.so.5.2.0, etc);

>CMakeLists.txt also assumes /(prefix)/lib for libraries:
>
>    SET(VTK_INSTALL_LIB_DIR
>     ${VTK_INSTALL_ROOT}/lib/vtk-${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION}
>
>This isn't correct on several Linux distros, which use /usr/lib64 for
>the x86-64 architecture.

Here you are assuming VTK_INSTALL_ROOT = /usr.
This is not what we intend, again so that we don't erase other 
libraries in the installation process (remember, we build tons of 
utilities libs in VTK, like libjpeg, libtiff, libpng, ffmpeg, etc, 
and even though we "mangle" and prefix them, you never know).
Again, we favor self-contained VTK installation trees, say, 
VTK_INSTALL_ROOT = /opt/vtk5.2

>because having the shared libraries in a subdirectory of /usr/lib
>doesn't work by default - it's not in ldconfig's path, so ldconfig
>doesn't find them, so vtk doesn't run. How is this expected to work,
>normally?

By modifying your LD_LIBRARY_PATH, or using static binaries, or 
creating launchers using KWSys, etc.