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

Matt McCormick matt.mccormick at kitware.com
Thu Dec 13 15:42:49 EST 2018


On Thu, Dec 13, 2018 at 1:48 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:

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

Thanks for the explanation.



>
> > - 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.
>
> Yes. And, as discussed below, there is an additional need for calling the
"find_dependency" macro as discussed below...



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


It sounds like the VTK modules created by ParaView needed to call
find_dependency(ParaView) like third party modules do that defer to the
configuration of system versions of libraries.



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

We support using third party libraries because there is a practical need
and desire to use them. There may be bugs in third party software. If there
are bugs in the third party software CMake configuration, then that
software cannot be used until it is fixed. If there is a bug introduced by
a third party VTK module, then that module cannot be used. I do not think
it is a show-stopper.



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


CMake functions to do all these things could be encapsulated and provided
instead of duplicated.



>
>
> > > > @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.
>
> Building as part of VTK is less of a priority, in my opinion, relative to
building externally. However, it does two helpful things 1) these modules
get exposed as an optional part of VTK's build configuration, which gives
the modules more exposure and makes VTK more exciting and 2) it avoids the
work required to set up a Superbuild.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20181213/37bdb5f0/attachment-0001.html>


More information about the vtk-developers mailing list