<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>> I'm not seeing a rationale</div><div><br></div><div>By ensuring the build system of a VTK/ITK/Slicer... modules is the same if it is built inside or outside the "main" application/libraries allows the following:</div><div><br></div><div>- avoid special case, tribal knowledge, ... : a module layout is consistent<br></div><div><br></div><div>- support for packaging independently some part</div><div><br></div><div><br></div><div>@Matt: Could you share your experience within the ITK community ? <br></div><div><br></div><div><br></div><div><br></div><div><span class="gmail-im">> > > Would this outside-VTK build expect to put its Python module under `vtkmodules` still?<br>> > Good question. When building wheels, the answer is yes. [...]</span></div><div>> The problem is that this breaks `vtkmodules.all.vtkOpenVROverlay` because `vtkmodules.all` only includes modules built by VTK itself. <br></div><div>> It means that we really shouldn't provide it at all if users have to know the module name anyways.<span class="gmail-im"><br></span></div><div><br></div><div>In a nutshell, python support the concept of "entry_points". Each time a vtk wheel associated with a module is installed, the namespace "vtk.modules" could automatically be updated with a new entry (e.g "vtk.modules.vtkopenvr"). Then, in the "all.py" we would make use of "pkg_resources.iter_entry_points" to import the associated classes.</div><div><br></div><div>As similar approach was adopted by Girder, see <a href="https://github.com/girder/girder/blob/cfb58ef245384fff7f90cf4cd6c8cab94510b9f6/plugins/homepage/setup.py#L47-L51">here </a><br></div><div><br></div></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">> The new wrapping code assumes VTK modules (i.e., built via `vtk_module_scan` and `vtk_module_build`). If the relevant properties aren't set on the target to be wrapped, they'll not do the right things.</div><div dir="ltr"><br></div><div>I see. By copying the relevant CMake functions from VTK 8.2, we should be able to keep things working.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br><div>> maybe RenderingOpenVR should just become a remote module instead?</div><div><br></div><div>Since adding a remote module simply means download the source, then call "add_subdirectory()" with two parameters. Unless a VTK module can be implemented so that it can be built inside and outside of the source tree, I don't think it will be supported.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><span class="gmail-im">> > - building of VTK/Rendering/OpenVR into a Slicer extension.<br>
<br></span>> Why is it not just used as a dependency like this?<br>> find_package(VTK COMPONENTS RenderingOpenVR)<br>> if (VTK_RenderingOpenVR_FOUND)<br>> add_subdirectory(openvr_ext)<br>> endif ()</div><div><br></div><div>Because:</div><div>* In order to reuse the install rules of the module and package it, we need the associated build tree.</div><div>* The build of VTK in Slicer proper has no dependency on openvr external project, this is lever to the SlicerOpenVR extension. See "SuperBuild" folder in <a href="https://github.com/KitwareMedical/SlicerVirtualReality">https://github.com/KitwareMedical/SlicerVirtualReality</a><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 12, 2018 at 5:17 PM 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 16:34:30 -0500, Robert Maynard wrote:<br>
> This is common in the wild ( see catch2 ) to such a degree that CMake<br>
> now has FetchContent which explicitly supports the workflow of using<br>
> find_package and than falling back to add_subdirectory. I expect that<br>
> this workflow will increase as FetchContent becomes more wildly<br>
> available.<br>
<br>
OK, so I do remember googletest also doing stuff like this. But these<br>
are test dependencies. Are there any that you can think of that do this<br>
for things like vtkzlib? Though there I suspect that no one does the<br>
proper mangling that needs to be done…<br>
<br>
Also, that's more like remote modules than what is being requested here.<br>
If that's the case, maybe RenderingOpenVR should just become a remote<br>
module instead?<br>
<br>
--Ben<br>
</blockquote></div>