[vtk-developers] VTK modularization: initial pass at new modules
Bill Lorensen
bill.lorensen at gmail.com
Wed Mar 9 11:43:20 EST 2011
Marcus,
Have you ever used the gcc -MM flag? It generates dependencies for a
source file.
Bill
On Wed, Mar 9, 2011 at 11:19 AM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Wed, Mar 9, 2011 at 11:02 AM, David Cole <david.cole at kitware.com> wrote:
>> On Wed, Mar 9, 2011 at 9:47 AM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>>
>>> Hi Andrew,
>>>
>>> On Tue, Mar 8, 2011 at 11:13 PM, Andrew Maclean
>>> <andrew.amaclean at gmail.com> wrote:
>>> > Hi Marcus,
>>> > Firstly congratulations to you all on a brilliant first effort.
>>> > One minor change, could I suggest moving:
>>> > [Filters/Sources]
>>> >
>>> > Graphics/vtkParametricFunctionSource.cxx:
>>> > Graphics/vtkParametricFunctionSource.h:
>>> >
>>> >
>>> > To:
>>> > [Core/ComputationalGeometry]
>>> > Logically vtkParametricFunctionSource belongs with the rest of the
>>> > vtkParametric classes.
>>>
>>> This is one case where it would be nice to keep it where it is. The
>>> Core/ComputationalGeometry module should only depend on Core/Core
>>> right now, but if we made this move then it would also depend on
>>> Core/ExecutionModel. Filters/Sources would of course link to
>>> Core/ExecutionModel, and to Core/ComputationalGeometry if necessary.
>>>
>>> That said I have not gotten this far with the build system, but I
>>> think it would be nice to keep the minimal dependency set for
>>> ComputationalGeometry if this is feasible.
>>>
>>
>> Perhaps the other vtkParametric classes belong wherever they need to belong
>> in order to minimize the dependencies then? Perhaps a Parametric module
>> itself somewhere?
>>
> That is pretty much what Core/ComputationalGeometry is right now (just
> depends on Core/Core). The name could be changed, but there may be
> other related classes that fit well there. The parametric source needs
> Core/ExecutionModel and Core/ComputationalGeometry. Putting it into
> ComputationalGeometry would then add an extra dependency to
> ComputationalGeometry on ExecutionModel.
>
> I would like to get these things building, and confirm my analysis is
> correct. It seems like keeping all of the source classes together is
> reasonable. I will try to get the inter-module dependencies tabulated
> in the short term so that we can more easily assess the impact. There
> are a few more things that I need to move around in order to get
> things building without reworking some of the classes anyway.
>
> Marcus
> _______________________________________________
> 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
>
>
More information about the vtk-developers
mailing list