[vtk-developers] Modules missing from the Standalone Group

[Bill Lorensen]

It seems the consensus is that Rendering + StandAlone should include all
classes that a pre-modularization VTK had by default. That's why I added
imaging modules and views modules to Rendering or StandAlone.

On Fri, Jul 20, 2012 at 12:59 PM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

> Reviewed, as I said in the review I am not sure about adding the views
> to the rendering group. If we really want to do that permanently is
> there really any utility in keeping the views group. I don't feel all
> that strongly as I am a regular user of the views and they make using
> rendering classes simpler on the whole.
>
> Marcus
>
> On Fri, Jul 20, 2012 at 9:19 AM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
> > Marcus,
> >
> > Can you review http://review.source.kitware.com/#/t/937/ ? I'd like to
> get
> > my errors resolved.
> >
> > Thanks,
> >
> > Bill
> >
> > On Fri, Jul 20, 2012 at 11:59 AM, Marcus D. Hanwell
> > <marcus.hanwell at kitware.com> wrote:
> >>
> >> On Thu, Jul 19, 2012 at 10:07 PM, Utkarsh Ayachit
> >> <utkarsh.ayachit at kitware.com> wrote:
> >> >>> FWIW, it might have been a good idea to provide nonintrusive API to
> >> >>> specify module groups.
> >> >>
> >> >> One suggestion along this route is to have groups just be special
> >> >> modules
> >> >> with nothing in them but a list dependent modules.
> >> >
> >> > That sounds like a good idea. It would need some fixes (since
> >> > currently it's not possible to have a module.cmake without a
> >> > CMakeLists.txt), but +1 from me.
> >>
> >> If there is a strong desire for that then we could probably add
> >> something, but it would be easier to just let you do this in the
> >> groups cmake file. I can see why you want this when establishing the
> >> groups, but I would argue that it breaks the modularity and for
> >> maintenance having that information with the module.cmake seems more
> >> logical to me.
> >>
> >> I think it is much nicer to add or remove a module by editing its
> >> metadata (module.cmake) rather than centralizing that knowledge to one
> >> or two files. That is why I implemented it this way, but groups are
> >> somewhat special and could be implemented either way. If there is
> >> consensus then I would much rather just add this information to
> >> vtkGroups.cmake instead of further complicating the modules.
> >>
> >> My $0.02, along with details on my thought processes as I wrote that
> >> code. We will then have to ensure that the groups are synced with the
> >> modules if their names change etc, it should normally be obvious
> >> pretty quickly, but for less widely used groups this could go
> >> unnoticed for longer periods.
> >>
> >> 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
> >>
> >
> >
> >
> > --
> > Unpaid intern in BillsBasement at noware dot com
> >
>



-- 
Unpaid intern in BillsBasement at noware dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120720/427464bd/attachment.html>