[vtk-developers] VTK modularization: initial pass at new modules

[Marcus D. Hanwell]

On Tue, Mar 8, 2011 at 5:33 PM, Clinton Stimpson <clinton at elemtech.com> wrote:
> On Tuesday, March 08, 2011 03:07:10 pm Marcus D. Hanwell wrote:
>> Hi,
>>
>> I have linked to a manifest file, this contains an early pass at
>> creating new VTK modules, as part of the VTK modularization project.
>> It maps source files, the old CMakeLists.txt, Testing and several
>> other parts have been intentionally left out for now. Once we have a
>> rough consensus on the classes that will go into the new kits we can
>> then map the tests to the appropriate places.
>>
>> https://github.com/cryos/vtk-modularization/blob/master/manifest.txt
>>
>> The [<ignore>] section marks files and directories that are not
>> mapped. All other sections denote new modules, for example,
>>
>> [Core/Core]
>> Common/vtkABI.h:
>>
>> Would map the vtkABI.h file currently in common to Core/Core/vtkABI.h
>> in the new modules. This would be a kit called vtkCoreCore. We are
>> planning on using two levels, with no modules in the first level and
>> only one word being allowed for top levels so that it is easy to
>> distinguish what the top level part of a library name is. This means
>> that the Core directory would contain several other modules that are
>> core libraries, with each module in the second level being a module.
>>
>> I am pushing this list while it is still at an early stage (largely
>> with input from Berk, Will and Jeff so far) so that the wider
>> community can comment on the proposed moves. None of the names or
>> mappings are set in stone, and we welcome your input (especially from
>> those of you who have spent a lot of time working on some of these
>> classes). I will be updating it as I get things building, and once a
>> reasonable subset of VTK is building I will put up an experimental
>> modularized VTK repository for people to test. The history of that
>> repository will not be retained, and all source changes should still
>> go to VTK master.
>>
>> As you can see some old modules have not been mapped yet (Imaging,
>> Parallel, Examples, Wrapping). I will let people know in advance of
>> the final move, the mappings will be applied to the latest source
>> files in master at that point using git file moves, and the new build
>> system committed. Until then I can update the experimental modularized
>> VTK by syncing to the latest source files in VTK master periodically.
>>
>> We would appreciate input from the wider VTK developer community as we
>> modularize VTK. This will also impact other communities, such as
>> ParaView and Slicer, and we are looking into ways to ease porting to
>> the new layout. I have talked at length with the ITK modularization
>> team to see what we can share, and will be putting that together in
>> the experimental repository soon.
>>
>
> Do you have a map of dependencies between modules?
> For some apps, I found that if I wanted to use one piece of another module, I
> had to bring in other modules that I didn't really need.
> For example, vtkWidgets has a small dependency on vtkHybrid.
>
This is one of the things we are working to tackle, by having more
granular modules. I will be building up the inter-module dependencies
as I work on the build system in parallel to these discussions
refining where the classes should go. This will be part of the build
system, and I would certainly appreciate feedback on this once it is
available.

Marcus