VTK/Modularization Proposal

From KitwarePublic
< VTK
Revision as of 10:49, 12 August 2010 by Berk (talk | contribs) (Created page with '== 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 …')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

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.