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

[Adam Williamson]

On Tue, 2008-10-21 at 17:50 -0400, Sebastien BARRE wrote:

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

I commiserate with your position of having to support crappy platforms,
then. ;) I will keep our changes in parallel. On a sane operating
system, they all make sense ;)

Just to note, in Linux, this does not at all compromise the possibility
of having multiple VTK versions installed, as the directory where the
TCL bits wind up is versioned like the others:

/usr/lib/tcl8.6/vtk-5.2

so, of course, there could also be a /usr/lib/tcl8.6/vtk-4.3 and
a /usr/lib/tcl8.6/vtk-6.0 . If you wanted.

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

No, of course not, you can always set TCLLIBPATH to whatever you like.
This only concerns the system default.

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

Yes, I figured that. I don't really remember where I was in the process
when I wrote that mail. I now have
{@CMAKE_INSTALL_PREFIX@@VTK_INSTALL_LIB_DIR@} in the patch in question.

> >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);

Yes. As I said, the point of using the versioned ones rather than the
unversioned ones is that on most Linux distributions, unversioned libs
are considered development stuff, and whatever package you put them in
winds up with a ton of development dependencies. But if there's a reason
you can't do this, that's fine. Just wanted to mention it.

In our packages, the unversioned .so files wind up in libvtk-devel and
tcl-vtk-devel (and python-vtk-devel).

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

Still, I think it would be correct in this instance to prefix the
libdir. But it's not a massively important point I guess.

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

Again, it is therefore clear that we have different ideal usage
scenarios :). Generally, in Mandriva, we want packages to install and
work immediately, and fit into the system environment as much as
possible. This is obviously not your intention upstream, so we will
maintain our changes in parallel.
-- 
adamw