Hi Folks, <br><br>From Slicer build system perspective, some important elements to consider:<br><br> - find_package(VTK .. COMPONENT ..) : Similarly to what ITKv4 proposed, the idea is to call find_package( .. ) within each library/module so that VTK_LIBRARIES is set accordingly<br>
<br> - installing just the RuntimeLibraries component should work. See [1]<br><br> - Library like vtkRendering shouldn't depend on Qt. Qt dependency should be introduced at the application level.<br><br> - Library like (vtk)zlib which are internally configured/build should be exposed or it should be possible to provide its own version. While working Slicer I factor out the zlib library from CMake because we needed it to build LibArchive. See [2] .. and it wasn't possible to depend on the one provided by VTK .. the header isn't designed for that.<br>
<br> - If not yet done, project like kwsys could also be factored out, it would be very helpful<br><br><br><br>I will bring the question of VTK 6.0 during our next TCon. That said, our focus is currently on the upcoming 4.1 release.<br>
<br>Thanks<br>Jc<br><br>[1] <a href="https://github.com/Slicer/Slicer/blob/master/CMake/SlicerBlockInstallCMakeProjects.cmake#L6">https://github.com/Slicer/Slicer/blob/master/CMake/SlicerBlockInstallCMakeProjects.cmake#L6</a><br>
[2] <a href="https://github.com/commontk/zlib">https://github.com/commontk/zlib</a><br><br><div class="gmail_quote">On Fri, Mar 23, 2012 at 5:38 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.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="im">On Fri, Mar 23, 2012 at 2:59 PM, Marcus D. Hanwell<br>
<<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>> wrote:<br>
> On Fri, Mar 23, 2012 at 4:02 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
>> Hi Marcus,<br>
>><br>
>> I've attached a patched manifest.txt that outlines my ideas for the<br>
>> modularization of Imaging.<br>
>><br>
>> Imaging/Core<br>
>> Imaging/General<br>
>> Imaging/Sources<br>
>> Imaging/Hybrid<br>
>> Imaging/Stencil<br>
>> Imaging/Morphological<br>
>> Rendering/Image<br>
>><br>
> Did you try compiling this, or it is just the split you feel is<br>
> appropriate? When it comes to compiling there can be further movement<br>
> necessary, but I can look into this a little.<br>
<br>
</div>Right now I'm hoping for a bit of feedback before I take that step.<br>
<div class="im"><br>
<br>
>> I've considered breaking things down even further, but I'm not sure if<br>
>> there would be a benefit to going this far:<br>
>><br>
>> Imaging/Color<br>
>> Imaging/Fourier<br>
>> Imaging/Math<br>
>> Imaging/Statistics<br>
>><br>
>> Actually, though, I really think that more people (developers and<br>
>> customers) need to provide feedback on the way the modules have been<br>
>> split up. A major reorganization like this requires lots of eyeballs.<br>
><br>
> We have sent out several calls, and have been circulating this list<br>
> among other developers and customers to get feedback. If there are<br>
> people you are thinking of specifically please let us know.<br>
<br>
</div>How much response have you gotten? I was lazy about looking into this<br>
myself (even though I've been aware of modular for a very long time),<br>
so I imagine that a lot of other developers are the same.<br>
<br>
I don't think that my list would be much different from yours: the<br>
core VTK developers (e.g. the Gerrit list), Sandia, Slicer3D, VisIt,<br>
VisTrails, and probably others that I've forgotten about.<br>
<div class="im"><br>
>> One of my major concerns right now is the OpenGL module. Any app that<br>
>> uses Rendering will have to use OpenGL, but because OpenGL depends on<br>
>> all the other Rendering modules, anyone who uses any part of rendering<br>
>> will have to link to all of Rendering.<br>
>><br>
>> I propose: the OpenGL classes should go into the various Rendering<br>
>> submodules that use them, e.g. vtkOpenGLCamera belongs with vtkCamera.<br>
>> You've already done this for the OpenGL classes that used to be in<br>
>> Charts: they are included in Rendering/Context2D.<br>
><br>
> I have the opposite view, I would like to split Rendering/Context2D up<br>
> but it needs some refactoring to make it interface + implementation. I<br>
> think most would stay in Rendering/Context2D and the stuff needing to<br>
> include OpenGL/make GL calls should move to Rendering/Context2DOpenGL<br>
> (or other name that makes sense).<br>
><br>
> One of our aims was to have the OpenGL implementation in a separate<br>
> module, and what we should probably do is split Rendering/OpenGL up<br>
> further for implementations of the various parts of Rendering.<br>
<br>
</div>That would also work. On a side note, I'd be interested to hear what<br>
the plans are for OpenGL ES. OpenGL and ES are so similar that it<br>
must be difficult to decide what code to share and what code to split.<br>
<span class="HOEnZb"><font color="#888888"><br>
- David<br>
</font></span><div class="im HOEnZb"><br>
<br>
> Thanks for looking into this, we will be pushing several larger<br>
> updates for the wrapping shortly as we have been concentrating on<br>
> getting the three wrapped languages working.<br>
</div><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"><br>-- <br>+1 919 869 8849<br><br>