[vtk-developers] VTK modularization update

Marcus D. Hanwell marcus.hanwell at kitware.com
Mon Mar 19 10:27:46 EDT 2012


On Sat, Mar 17, 2012 at 7:41 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi Bill,
>
> I prefer having the sources explicitly listed in the cmake files.  Why
> did the ITK folks decide to go the other way?

I see Bill cleared this up, they do list these out but have quite a few levels.
>
> Overall, I'm a fan of the VTK modularization.  It does the three
> things that I wanted to see:
>
> 1) it simplifies the kit CMake scripts, making it easy to add new kits
> 2) it makes it easy to add external kits (and wrap them)
> 3) it reorganizes the directories to reflect how VTK has evolved
>
> And it achieves this with a fairly minimal set of changes to the
> overall organization of VTK, which is something that I really
> appreciate.  But I agree that code tools should be in a different
> directory from the library source.  The code tools could stay in
> "Utilities" (with the lib source moved to a different directory), or
> the code tools could go into a directory called CodeTools (with the
> lib source remaining in Utilities). I like the name "CodeTools"
> because it is less ambiguous than "Utilities".

We were attempting to put all third party libraries in ThirdParty to
make it clear that they are not VTK code and also ensure consistent
handling (use system copies of all libraries in here if requested).
Separating out the code tools from the utility libraries sounds
reasonable to me.

One of the things we decided very early on was to only have a
directory structure two deep (currently one deep in master) for the
libraries and main code. I think that this works really well, we have
not used the top level Modules directory ITK has, nor the src and
include subdirectories for each module.

We have chosen to keep Testing as a subdirectory for each of the
modules, with the familiar Cxx, Python, Tcl subdirectories. We are
using logic from the top to only activate the tests when the module is
enabled and the language wrapping for that type is on, reducing the
amount of boiler plate necessary in each CMakeLists both at the module
and module test levels.
>
> And of course Imaging still needs to be split... I'll take a shot at
> this next week, and maybe Steve Piper should take a look too.
>
I am still a little concerned about two of my modules - Charts and
Chemistry. It seems to me that they should not be top level at all,
and neither are likely to grow to the state where they have many
modules, we already split the 2D rendering off into
Rendering/Context2D. Ideas for a broad top level with focused modules
such as charts, chemistry, physics might be a possibility.

Thanks for the feedback.

Marcus



More information about the vtk-developers mailing list