I’ve installed vtk version 9.1.0-r4 on my linux system using the package manager, and have also compiled version 9.1.0-r4 from source
The package manager installed version has libraries:
libvtkCommon-9.1.so
libvtkRendering-9.1.so
libvtkInteraction-9.1.so
libvtkFilters-9.1.so
The self-compiled version has libraries:
libvtkCommonCore-9.1.so
libvtkRenderingCore-9.1.so
libvtkInteractionStyle-9.1.so
libvtkFiltersCore-9.1.so
Is there a CMake option to choose one naming convention or the other? The project I am incorporating vtk into doesn’t use CMake, so I can’t rely on automatic library discovery to bypass the naming issue. Tried diffing the CMakeCache.txt files, but nothing was immediately obvious.
It looks like the package manager enabled “kits”. This is a flag to minimize the number of share libraries on the system. It’s intended for HPC systems where filesystem access to load libraries doesn’t scale well with the number of files to open.
Note that using VTK (especially 9+) requires some level of CMake in order to have object factories work. This is the mechanism whereby you request a vtkOpenGLRenderWindow and actually get an X-using subclass. Something like this tool for ParaView could be adapted to work for VTK as well.
Oh, that tool still doesn’t get you autoinit stuff. Non-CMake projects will need that to be manual. But it can at least get the compile and link flags necessary.
-DVTK_ENABLE_KITS=ON was what I was after, thank you.
Manually specifying the required vtk libraries in a makefile seems to work for the functionality I’m after. I did discover the need to specify the autoinit manually to get OpenGL rendering. It was a puzzling exercise to figure out why rendering wasn’t working until I found out that CMake injects headers during the build.