[vtk-developers] VTK modularization update

Mon Apr 2 19:35:56 EDT 2012

Hi Folks,

>From Slicer build system perspective, some important elements to consider:

  - find_package(VTK .. COMPONENT ..) : Similarly to what ITKv4 proposed,
the idea is to call find_package( .. ) within each library/module so that
VTK_LIBRARIES is set accordingly

  - installing just the RuntimeLibraries component should work. See [1]

  - Library like vtkRendering shouldn't depend on Qt. Qt dependency should
be introduced at the application level.

  - Library like (vtk)zlib which are internally configured/build should be
exposed or it should be possible to provide its own version. While working
Slicer I factor out the zlib library from CMake because we needed it to
build LibArchive. See [2] .. and it wasn't possible to depend on the one
provided by VTK .. the header isn't designed for that.

  - If not yet done, project like kwsys could also be factored out, it
would be very helpful

I will bring the question of VTK 6.0 during our next TCon. That said, our
focus is currently on the upcoming 4.1 release.

Thanks
Jc

[1]
https://github.com/Slicer/Slicer/blob/master/CMake/SlicerBlockInstallCMakeProjects.cmake#L6
[2] https://github.com/commontk/zlib

On Fri, Mar 23, 2012 at 5:38 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> On Fri, Mar 23, 2012 at 2:59 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
> > On Fri, Mar 23, 2012 at 4:02 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >> Hi Marcus,
> >>
> >> I've attached a patched manifest.txt that outlines my ideas for the
> >> modularization of Imaging.
> >>
> >> Imaging/Core
> >> Imaging/General
> >> Imaging/Sources
> >> Imaging/Hybrid
> >> Imaging/Stencil
> >> Imaging/Morphological
> >> Rendering/Image
> >>
> > Did you try compiling this, or it is just the split you feel is
> > appropriate? When it comes to compiling there can be further movement
> > necessary, but I can look into this a little.
>
> Right now I'm hoping for a bit of feedback before I take that step.
>
>
> >> I've considered breaking things down even further, but I'm not sure if
> >> there would be a benefit to going this far:
> >>
> >> Imaging/Color
> >> Imaging/Fourier
> >> Imaging/Math
> >> Imaging/Statistics
> >>
> >> Actually, though, I really think that more people (developers and
> >> customers) need to provide feedback on the way the modules have been
> >> split up.  A major reorganization like this requires lots of eyeballs.
> >
> > We have sent out several calls, and have been circulating this list
> > among other developers and customers to get feedback. If there are
> > people you are thinking of specifically please let us know.
>
> How much response have you gotten?  I was lazy about looking into this
> myself (even though I've been aware of modular for a very long time),
> so I imagine that a lot of other developers are the same.
>
> I don't think that my list would be much different from yours: the
> core VTK developers (e.g. the Gerrit list), Sandia, Slicer3D, VisIt,
> VisTrails, and probably others that I've forgotten about.
>
>  >> One of my major concerns right now is the OpenGL module.  Any app that
> >> uses Rendering will have to use OpenGL, but because OpenGL depends on
> >> all the other Rendering modules, anyone who uses any part of rendering
> >> will have to link to all of Rendering.
> >>
> >> I propose: the OpenGL classes should go into the various Rendering
> >> submodules that use them, e.g. vtkOpenGLCamera belongs with vtkCamera.
> >> You've already done this for the OpenGL classes that used to be in
> >> Charts: they are included in Rendering/Context2D.
> >
> > I have the opposite view, I would like to split Rendering/Context2D up
> > but it needs some refactoring to make it interface + implementation. I
> > think most would stay in Rendering/Context2D and the stuff needing to
> > include OpenGL/make GL calls should move to Rendering/Context2DOpenGL
> > (or other name that makes sense).
> >
> > One of our aims was to have the OpenGL implementation in a separate
> > module, and what we should probably do is split Rendering/OpenGL up
> > further for implementations of the various parts of Rendering.
>
> That would also work.  On a side note, I'd be interested to hear what
> the plans are for OpenGL ES.   OpenGL and ES are so similar that it
> must be difficult to decide what code to share and what code to split.
>
>  - David
>
>
> > Thanks for looking into this, we will be pushing several larger
> > updates for the wrapping shortly as we have been concentrating on
> > getting the three wrapped languages working.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>

-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120402/6f1faf88/attachment.html>