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

[Darren Weber]

Please see my recent post on the cmake list about the possibility to specify
library paths etc. to the cmake build that will automatically follow through
into all the cmake Module paths.  In most cases, even if you configure the
build for a given port (some linux variant or whatever), all the cmake
Modules, like FindVTK.cmake, have hard-coded search paths for the library.
We really need a way to specify those module search paths during the porting
process (ie, arguments to Cmake).

Regards,
Darren




On Tue, Oct 21, 2008 at 3:02 PM, Adam Williamson
<awilliamson at mandriva.com>wrote:

> 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
>
> _______________________________________________
> This is the private VTK discussion list.
> Please keep messages on-topic. Check the FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20090609/e173fb5b/attachment.htm>