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

[Ben Boeckel]

On Thu, Dec 13, 2018 at 13:16:40 -0500, Matt McCormick wrote:
> - Required CMake settings are stored in VTKConfig.cmake

VTK's new vtk-config.cmake, right now exports this set of variables:

  VTK_VERSION VTK_LEGACY_REMOVE VTK_HAS_VTKm VTK_OPENGL_HAS_EGL
  VTK_WRAP_PYTHON VTK_WRAP_JAVE VTK_PYTHONPATH VTK_LIBRARIES

And variables which don't make sense aren't set at all (e.g.,
VTK_OPENGL_HAS_EGL is only set if the VTK::opengl module has been
built and VTK_PYTHONPATH is only set if Python wrapping has been
enabled). VTK_LIBRARIES is just the list of targets from COMPONENTS and
OPTIONAL_COMPONENTS that have been requested. If no components are
requested, VTK_LIBRARIES is empty.

No other variables are required to use VTK from CMake, so they aren't
provided.

> - There is a VTKTargets.cmake that contains all the target information from
> the main build.

Eh, there's more than that now because CMake only exports properties it
deems as important. Other sidecar files exist too.

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

vtk-config.cmake doesn't support dropping things in here. The new module
system has this:

  VTK-targets.cmake
  VTK-vtk-module-properties.cmake
  VTK-vtk-module-find-packages.cmake (uses components to only find what
  was requested)
  VTK-vtk-python-module-properties.cmake (if Python wrapping is enabled)

The old module system globbing for this information has historically not
worked out well. I don't want to continue that mistake. Concretely, in
an install of ParaView, `find_package(VTK)` didn't work because ParaView
modules were included in VTK's glob and assumed variables were set that
only ParaView's config provided. This errored out and made it impossible
to use without setting a magic ParaView variable before finding VTK. I
really don't want people to say "find VTK doesn't work" because some
other project dropped a broken CMake file in its CMake configuration
directory.

> The module contains minimal CMake setup, but that is required for any
> project that depends on VTK.

Yes, that is not "a few lines". It involves finding VTK, scanning
modules, making sure that the found VTK provides the required modules,
building modules, optionally wrapping, installing CMake configuration
files, etc. And that doesn't include packaging. It's hard enough to make
sure VTK's CMake code works well that I don't want to try and also fix
it for projects using VTK at the same time (and as soon as they are not
basically VTK-module-only projects, they're on their own anyways).

> > > @Matt: Could you share your experience within the ITK community ?
> >
> > <Matt's reply>
> >
> > This seems more like remote modules as a path for migrating *into* VTK.
> > Building OpenVR separately is like moving it *out* of VTK. *That* is
> > what I don't understand.
> >
> 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.

Agreed. My follow-up: why do they have to support being built *as part
of VTK* then? Why is `find_package(VTK)` not sufficient as the *only*
way to build these projects like with every other dependency? I know the
existing module system wrapping and such wasn't nice outside of VTK, but
that is now fixed.

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

That's an argument for a separate repo to me…

--Ben