<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 13, 2018 at 11:50 AM Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Dec 12, 2018 at 19:08:30 -0500, Jean-Christophe Fillion-Robin wrote:<br>
> > I'm not seeing a rationale<br>
> <br>
> By ensuring the build system of a VTK/ITK/Slicer... modules is the same if<br>
> it is built inside or outside the "main" application/libraries allows the<br>
> following:<br>
<br>
It *cannot* be the same. `find_package(VTK)` only contains the<br>
information VTK had at the time of *its* build. Modules built outside of<br>
it won't show up. If a module is part of VTK, VTK does lots of heavy<br>
lifting one-time-setup things. Install directories, minimum CMake<br>
version, CMake policies, etc. Any standalone module will have to copy<br>
that information. I suspect that's at least 100 lines of CMake code<br>
(some of which can't be abstracted out).<br>
<br>
> - avoid special case, tribal knowledge, ... : a module layout is consistent<br>
<br>
This support itself is a special case itself AFAICS. Module layouts are<br>
consistent right now. Modules which do this are going to be the<br>
different ones.<br>
<br>
> - support for packaging independently some part<br>
<br>
That's just more code that modules will have to duplicate from VTK.<br></blockquote><div><br></div><div>The suggested duplication is not necessary.</div><div><br></div><div>To implement, on a high level:</div><div><br></div><div>- Required CMake settings are stored in VTKConfig.cmake</div><div>- There is a VTKTargets.cmake that contains all the target information from the main build.<br></div><div>- <module>Targets.cmake contains module target information. This is kept in an "index" (a certain folder relative to VTKConfig.cmake) that is searched and loaded by VTKConfig.cmake</div><div><br></div><div>The module contains minimal CMake setup, but that is required for any project that depends on VTK.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> @Matt: Could you share your experience within the ITK community ?<br>
<br>
<Matt's reply><br>
<br>
This seems more like remote modules as a path for migrating *into* VTK.<br>
Building OpenVR separately is like moving it *out* of VTK. *That* is<br>
what I don't understand.<br><br></blockquote><div>It is not possible or desirable for everything to move into VTK. On one side, the barrier to entry into VTK is high, and and on the other side, centralized maintenance cannot sustainably maintain everything under the sun. Distributed development of domain specific, etc., modules will be helpful.  </div><div><br></div><div>OpenVR, for example, requires special hardware and software to test. Separate development and testing enables folks to set up independent testing on configuration that satisfy its dependencies.</div><div><br></div><div>- Matt</div></div></div>