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.<br><br><div class="gmail_quote">
On Fri, Jul 20, 2012 at 12:59 PM, 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">
Reviewed, as I said in the review I am not sure about adding the views<br>
to the rendering group. If we really want to do that permanently is<br>
there really any utility in keeping the views group. I don't feel all<br>
that strongly as I am a regular user of the views and they make using<br>
rendering classes simpler on the whole.<br>
<span class="HOEnZb"><font color="#888888"><br>
Marcus<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Jul 20, 2012 at 9:19 AM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>> wrote:<br>
> Marcus,<br>
><br>
> Can you review <a href="http://review.source.kitware.com/#/t/937/" target="_blank">http://review.source.kitware.com/#/t/937/</a> ? I'd like to get<br>
> my errors resolved.<br>
><br>
> Thanks,<br>
><br>
> Bill<br>
><br>
> On Fri, Jul 20, 2012 at 11:59 AM, Marcus D. Hanwell<br>
> <<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>
>><br>
>> 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<br>
>> >> 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>
>> 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>
>><br>
>> Marcus<br>
>> _______________________________________________<br>
>> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>><br>
>> Visit other Kitware open-source projects at<br>
>> <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>
><br>
><br>
><br>
> --<br>
> Unpaid intern in BillsBasement at noware dot com<br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Unpaid intern in BillsBasement at noware dot com<br><br>