[vtk-developers] Modules missing from the Standalone Group

[Jeff Baumes]

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.
>

I agree that having lists in vtkGroups.cmake is a fine solution too, and I
realize I may be naive in thinking that empty modules for groups would
"just work", since there are probably many assumptions about modules that
would need to be recoded in order to allow VTK to handle empty modules. I
see the case for decentralization too, but it seems a group is a global
static entity. A particular module maintainer should not be in charge of
what groups they are in, that is a higher-level issue, so code organization
should reflect this. Perhaps we should keep the current decentralized
method as modules are more dynamic until near VTK 6.0 release, at which
point I assume module naming/organization would settle down and we could
hard-code the groups in vtkGroups.cmake.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120720/734be7cf/attachment.html>