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.

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

Issues

Backwards Compatibility

Renaming and reorganizing the kits will require that all consumers of VTK change their link commands.