[vtk-developers] vtk-8.2.0-rc2 problem building wheels

[Jean-Christophe Fillion-Robin]

> I'm not seeing a rationale

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:

- avoid special case, tribal knowledge, ... : a module layout is consistent

- support for packaging independently some part


@Matt: Could you share your experience within the ITK community ?



> > > Would this outside-VTK build expect to put its Python module under
`vtkmodules` still?
> > Good question. When building wheels, the answer is yes. [...]
> The problem is that this breaks `vtkmodules.all.vtkOpenVROverlay` because
`vtkmodules.all` only includes modules built by VTK itself.
> It means that we really shouldn't provide it at all if users have to know
the module name anyways.

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.

As similar approach was adopted by Girder, see here
<https://github.com/girder/girder/blob/cfb58ef245384fff7f90cf4cd6c8cab94510b9f6/plugins/homepage/setup.py#L47-L51>



> 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.

I see. By copying the relevant CMake functions from VTK 8.2, we should be
able to keep things working.



> maybe RenderingOpenVR should just become a remote module instead?

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.




> > - building of VTK/Rendering/OpenVR into a Slicer extension.

> Why is it not just used as a dependency like this?
>    find_package(VTK COMPONENTS RenderingOpenVR)
>    if (VTK_RenderingOpenVR_FOUND)
>      add_subdirectory(openvr_ext)
>    endif ()

Because:
* In order to reuse the install rules of the module and package it, we need
the associated build tree.
* 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 https://github.com/KitwareMedical/SlicerVirtualReality






On Wed, Dec 12, 2018 at 5:17 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Wed, Dec 12, 2018 at 16:34:30 -0500, Robert Maynard wrote:
> > This is common in the wild ( see catch2 ) to such a degree that CMake
> > now has FetchContent which explicitly supports the workflow of using
> > find_package and than falling back to add_subdirectory. I expect that
> > this workflow will increase as FetchContent becomes more wildly
> > available.
>
> OK, so I do remember googletest also doing stuff like this. But these
> are test dependencies. Are there any that you can think of that do this
> for things like vtkzlib? Though there I suspect that no one does the
> proper mangling that needs to be done…
>
> Also, that's more like remote modules than what is being requested here.
> If that's the case, maybe RenderingOpenVR should just become a remote
> module instead?
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20181212/7d669f90/attachment.html>