Marcus,<div><br></div><div>Can you review <a href="http://review.source.kitware.com/#/t/937/">http://review.source.kitware.com/#/t/937/</a> ? I'd like to get my errors resolved.</div><div><br></div><div>Thanks,</div><div>
<br></div><div>Bill<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>
<br>
My $0.02, along with details on my thought processes as I wrote that<br>
code. We will then have to ensure that the groups are synced with the<br>
modules if their names change etc, it should normally be obvious<br>
pretty quickly, but for less widely used groups this could go<br>
unnoticed for longer periods.<br>
<span class="HOEnZb"><font color="#888888"><br>
Marcus<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Unpaid intern in BillsBasement at noware dot com<br><br>
</div>