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

[Marcus D. Hanwell]

On Thu, Mar 10, 2011 at 3:22 PM, David Thompson <dcthomp at sandia.gov> wrote:
> Hi Marcus,
>
> I'm glad to see the modularization work moving along. It looks neat. There
> are a few comments/questions below.

Thanks for posting the visualization of this too - it is interesting to look at.
>
>> I have linked to a manifest file, this contains an early pass at
>> creating new VTK modules, as part of the VTK modularization project.
>> ...
>> https://github.com/cryos/vtk-modularization/blob/master/manifest.txt
>>
>> ... 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. ...
>>
>> ... None of the names or
>> mappings are set in stone, and we welcome your input ...
>
> 1. Core/Core is awkward. How about Basic/{Core, DataModel, ExecutionModel,
> ImplicitFunctions, Math, Misc, System, Transforms}?

Basic doesn't seem to fit, but perhaps a Core/Common would be a better name?
>
> 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. Would Filtering/General be
reasonably descriptive. I would like to avoid Misc if possible as much
as possible, but that may also be a good one to use.
>
> 3. Is all of Views is being placed under Infovis/Views? This doesn't seem
> right; the view & representation abstraction should be a kit-wide strategy,
> not something reserved for infovis. Maybe Views/Core (with the base classes
> and RenderView?) and Views/Infovis are in order?
>
I think this is a good point. I will take a look at that.

> 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.
>
> 5. How will include files be handled? Will it be #include
> <VTK/Core/Core/vtkAbstractArray.h> or #include <vtkAbstractArray.h> or
> something else? Even though it's longer, I prefer the former because it
> greatly simplifies the compiler command lines which makes them much easier
> to parse when debugging issues that require manually running the compiler.
>
Considering installation, directory layout etc, I think
<Core/Core/vtkAbstractArray.h> would be the simplest to implement, but
we could add a top level VTK. This would be a fairly big departure
from what we had before, but would reduce our link lines and make
installed include directories more navigable too.

I am in favor of moving to use this, but it would introduce quite a
few source level changes. It is on my list, but I want to get things
building first.

Marcus