VTK/Modularization Proposal
Abstract
As VTK continues to grow, the granularity that was originally chosen for the kits is becoming too coarse. For example, the Graphics kit contains 556 files and it depends on the Common and Filtering kits which contain 942 files between them. Therefore, to use a single filter from the Graphics kit, the developer has to link against 3 large libraries. This is specially problematic when linking against shared libraries. Wrapping tends to make things worse because it brings in all symbols from all libraries. Another issue is that there are optional classes in many of the kits. This means that there are many ways of building the kits, which makes it hard for package managers. We propose to rearrange VTK's kits to address these problems.
Use Cases
Ability to Link Against a (Somewhat) Minimal Subset of VTK
It should be possible to link against a reasonable subset of VTK depending on what part of VTK are used. Some people want to use only VTK's data model. Others want to use it as a rendering library. In the first case, it should be possible to link against a common (core?) library and the data model library without bringing in the execution model and bunch of unnecessary utility classes. In the second case, it should be possible to link against common, data model and execution model - no need to bring in bunch of filters.
Ability to Include a Minimal Subset of VTK
This is somewhat different than the above use cases. More and more, application codes want to embed a subset of VTK. Currently, the only way to do this is to pull in the whole thing. It should be possible to pick and choose kits (as long as the dependencies are satisfied) to be embedded in an application. This requires that the build system handles the absence of some of the kits.
Making Sense of VTK Kits
Currently, VTK kits are poorly named. Filtering contains only the execution model and filter superclasses but no concrete filters. Graphics contains feature extraction algorithms and computational geometry algorithms (and more) etc etc. The developer should be able to make a good guess about what is in a kit from its name.
Binary Package Management
In the VTK 5.6 and 5.8 releases, the vtkRendering library uses Qt, which causes difficulty for maintainers of binary VTK packages. For example, the ubuntu/debian binary packages for VTK 5.2 include:
- libvtk5 libvtk5-qt3 libvtk5-qt4 libvtk-java vtk-tcl python-vtk vtkdata
This package breakdown is not possible if one of the main VTK libraries depends on Qt. In the VTK 5.6 debian packages, libvtk5 now depends on qt4 (which in itself is bad), and libvtk5-qt3 is gone since this dependency made it impossible to support qt3. The same rule applies for any optional third-party library that can be used by VTK: classes that depend on that third-party library should be contained within their own VTK library whenever possible. --Dgobbi
Proposed Work
Reorganize VTK
- Rename existing kits such that the names make sense
- Create new kits
- Clean up dependencies
Clean up VTK's CMake files
VTK does not use most of the newer CMake functionality. We should modernize VTK's CMake files while doing the reorganization such that it is more easily maintained by non-CMake-experts (i.e. those other than Bill, Brad and Dave Cole)
- I know that changing the include directives to require the kit name in front of the class name has been discussed before. If possible, I would like to make that change as the kits names are changed and CMake files updated. With more intuitive kit names, this should not be a burden and it will reduce the size of the compiler command line, especially in the face of having even more kits. --Dcthomp
Allow for the compilation of subsets of VTK
Change VTK's CMake files such that they gracefully handle the absence of kits, as long as the dependencies are satisfied. It should be possible to delete bunch of subdirectories from VTK and still have what is left configure and compile properly.
Allow for instantiator to be turned off?
Any chance these changes could include the ability to turn off the vtkInstantiator on a per-kit or per-class basis? Perhaps a single CMake variable could point to a file containing classes for which instantiators should be generated would be OK? --Dcthomp
Make sure that Java Native Library loading play well with VTK
Make sure that the build system do provide all the configuration so VTK can be easily used through Java Web Start applications or OSGi framework. Maybe provide a packaging in the install rule for those usage where the libraries are stored into a vtk-6.xx-native.jar file.
See Bug for other informations: http://public.kitware.com/Bug/view.php?id=11398
Issues
Backwards Compatibility
Renaming and reorganizing the kits will require that all consumers of VTK change their link commands.
