<br><br><div class="gmail_quote">On Fri, Jul 20, 2012 at 11:59 AM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Thu, Jul 19, 2012 at 10:07 PM, Utkarsh Ayachit<br>
<<a href="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>> wrote:<br>
>>> FWIW, it might have been a good idea to provide nonintrusive API to<br>
>>> specify module groups.<br>
>><br>
>> One suggestion along this route is to have groups just be special modules<br>
>> with nothing in them but a list dependent modules.<br>
><br>
> That sounds like a good idea. It would need some fixes (since<br>
> currently it's not possible to have a module.cmake without a<br>
> CMakeLists.txt), but +1 from me.<br>
<br>
</div></div>If there is a strong desire for that then we could probably add<br>
something, but it would be easier to just let you do this in the<br>
groups cmake file. I can see why you want this when establishing the<br>
groups, but I would argue that it breaks the modularity and for<br>
maintenance having that information with the module.cmake seems more<br>
logical to me.<br>
<br>
I think it is much nicer to add or remove a module by editing its<br>
metadata (module.cmake) rather than centralizing that knowledge to one<br>
or two files. That is why I implemented it this way, but groups are<br>
somewhat special and could be implemented either way. If there is<br>
consensus then I would much rather just add this information to<br>
vtkGroups.cmake instead of further complicating the modules.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Jeff</div></div>