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

Ben Boeckel ben.boeckel at kitware.com
Tue Dec 11 18:55:04 EST 2018


On Tue, Dec 11, 2018 at 18:08:12 -0500, Jean-Christophe Fillion-Robin wrote:
> > The new module system doesn't support this at the moment [...] The
> > problem with this is that if a module can be built inside and outside of VTK
> 
> I see. That shouldn't be a problem, we can always do the following:

You trimmed the important part of that. It isn't impossible. But the
better question is "should we?".

> if(NOT VTK_SOURCE_DIR)
>   // find method 1
> else()
>   // find method 2
> endif()

The thing is that the module is incompatible from a consumer point of
view in the two builds. One makes `VTK::RenderingOpenVR` and is provided
via `find_package(VTK COMPONENTS RenderingOpenVR)`. The other…isn't.
IMO, if the module can't be built as part of VTK often enough to be
expected in a VTK build (e.g., pip or a Linux package), then it should
just be in a separate repository.

Also, the amount of code in that first one is not trivial:

    find_package(VTK COMPONENTS CommonCore IOImage ...)
    vtk_module_scan(...)
    vtk_module_build(...)
    vtk_module_wrap_python(...)

and that still isn't going to work because it will need to detect when
the module system is including the CMakeLists.txt file (or it just needs
to be a separate directory completely). Would this outside-VTK build
expect to put its Python module under `vtkmodules` still? Either way, I
really don't want modules doing this kind of stuff. Either it's part of
VTK or it isn't.

> 1. Looking at the "new-cmake-module" branch, are the "vtkLocal" and "vtkMy"
> examples up-to-date ?

I haven't looked at them yet. Other examples have been updated though.

> https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkLocal/CMakeLists.txt
> https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkMy/CMakeLists.txt
> 
> 2. Are the functions vtk_module_add_module, vtk_module_link, ... designed
> to be used outside of VTK build tree ?

Yes. VTK has no special inside-variable control over the code.
Everything is passed in via parameters to the functions, so VTK's
install directory variables are just parameters to this function. I'd
like to keep it that way.

> 3. To test the updated build system with Slicer, would it be possible to
> rebase the branch "new-cmake-module" ?

I've just rebased it today actually (for a ParaView rebase). Does Slicer
make VTK modules itself or just consume them?

--Ben


More information about the vtk-developers mailing list