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

[Marcus D. Hanwell]

I made quite a few changes, and think I have covered most points
raised. I also did some work to get a vtkCommonCore module building.
This required a few moves back to CommonCore, and I added comments
with reasons why each move was required.

This required the removal of several functions in vtkMath.h using
vtkPolynomialSolversUnivariate.h. We could of course move that back in
too. I still have some more work to do, but a local Linux build is
working now. Thank you for all of the suggestions. I have been looking
through all of the ITK modularization build code to re-use, and will
be working on that.

https://github.com/cryos/vtk-modularization/blob/master/manifest.txt

I think we have more consistency now. I have a few pending moves from
David Gobbi I have not yet applied (most of them are in).

Marcus

On Thu, Mar 10, 2011 at 7:51 PM, David Thompson <dcthomp at sandia.gov> wrote:
>> ...
>> Basic doesn't seem to fit, but perhaps a Core/Common would be a better
>> name?
>
> How about Common/Core? Common is familiar and those libraries really are
> common dependencies. That way there can be Filtering/Core instead of
> Filtering/Common which would be confusing for existing VTK developers.
>
>>> 2. Filtering/Filtering is not descriptive. How about Filtering/General or
>>> Filtering/Misc?
>>
>> Yes, I think would be good. It is perhaps best to avoid repeating the
>> same name twice in any of the kit names.
>
> I agree.
>
>> Would Filtering/General be reasonably descriptive.
>
> I think so. They are general-purpose filters that aren't part of a
> functional group of filters. Although you might be able to break some out,
> there generally aren't enough classes to justify a separate library. For
> instance, you could have Filters/Multiblock for filters that aggregate or
> extract multiblock datasets. Those tend to get used together frequently. In
> fact, one thing that surprised me about the mapping is how little it
> segregates things by the data representation, given that many applications
> will stick to using just one or two (e.g., the statistics filters use
> multiblock and table datasets, but not polydata, image data, unstructured
> grids, etc.). I guess there are enough filters that just operate on dataset
> attributes (scalars/vectors/...) that it doesn't make sense, but I'm curious
> whether you considered splitting Core/DataModel into Core/{GridModel
> (regular sampling on a grid), MeshModel (unstructured), GraphModel, etc.}?
>
>> I would like to avoid Misc if possible as much
>> as possible, but that may also be a good one to use.
>
> I agree that Misc should be avoided when possible.
>
>>> 4. You said all the kits would be in a 2-deep hierarchy, but several
>>> appear
>>> at the top layer: AMR, TextAnalysis, Geovis. Should those be AMR/Core,
>>> TextAnalysis/Core, Geovis/Core?
>>
>> Yes, that could be a good starting point for a name. I was hoping
>> those with better knowledge of those kits might come forward and tell
>> me when the ideal organization would be there.
>
> For Geovis you could split out the core functionality from the
> view+representation classes. The whole library is pretty closely tied to
> rendering, so I don't see a point in trying to separate out rendering code
> from Core, but this:
>
> [Geovis/Views]
> Geovis/vtkGeoView.h
> Geovis/vtkGeoView.cxx
> Geovis/vtkGeoView2D.h
> Geovis/vtkGeoView2D.cxx
> Geovis/vtkGeoAlignedImageRepresentation.h
> Geovis/vtkGeoAlignedImageRepresentation.cxx
>
> [Geovis/Core]
> everything else
>
> would keep Geovis/Core independent of Views/Core.
>
>        David
>
>
>