Building vtkbool as a remote module does not seem to complete.

Support
1

Hello,

I am trying to build vtkbool as a remote module of VTK 9.5 within Slicer’s build tree.

This vkbool.remote.cmake file is used:

# 
# vtkbool Classes
# 

vtk_fetch_module(vtkbool
“Boolean operations on polydata”
GIT_REPOSITORY https://github.com/zippy84/vtkbool
GIT_TAG 167d78255bc094893907b9151d7fdf685050c15b
)

In Slicer’s External_VTK.cmake file, these are added:

-DVTK_MODULE_ENABLE_VTK_vtkbool:STRING=WANT
-DVTKBOOL_PARAVIEW:BOOL=OFF

The CMakeCache.txt file contains:

VTK_MODULE_ENABLE_VTK_vtkbool:STRING=WANT
//Enable the vtkbool module. This module contains a class to do
VTK_MODULE_ENABLE_vtkbool:STRING=DEFAULT
//ADVANCED property for variable: VTK_MODULE_ENABLE_vtkbool
VTK_MODULE_ENABLE_vtkbool-ADVANCED:INTERNAL=1
//STRINGS property for variable: VTK_MODULE_ENABLE_vtkbool
VTK_MODULE_ENABLE_vtkbool-STRINGS:INTERNAL=YES;WANT;DOWNTOWN;NO;DEFAULT

When VTK is built, vtkbool is rightly downloaded in VTK/Remote/ and the build completes.

I am not sure if vtkbool has really been built because I don’t find any *PolyDataBoolean*.o* files in the build tree.

If vtkbool is built independently of Slicer as a test, such a file is created.

Is it built, incorporated in a library with deletion of the object files? That seems doubtful.

What should be expected with a successful build of vtkbool?

I have already read multiple posts on the forum, they deal with other kinds of problem regarding vtkbool.

Thank you for any guidance.

2

The remote module system is a legacy support mechanism. No remote modules are regularly tested in CI (mainly because fixing them is not part of VTK’s workflow, so breaking CI for external code isn’t viable). Feel free to submit MRs to fix the remote module configuration as needed, but I really think building vtkbool against an installed VTK build is the way to go rather than trying to have VTK build it itself.

3

Thank you very much, this is a valuable information, there is no reason to persist in a dead end then.

4

Just for completeness, remote modules existed in the first place because VTK’s install tree was not set up to do everything VTK consumers would want to do in a convenient way (or, in some cases, wasn’t even possible). When I reworked the system in 2018/2019, making sure the install tree was a perfectly viable way to make “VTK modules” was a key point on the design list. In fact, VTK uses it just as any other project would use it (it’s just that it comes from its own repo rather than a find_package).

5

This could have been one of the reasons for introducing remote modules. However, the main motivation for remote modules is that that they make community contributions easily accessible, without forcing library core developers to take on additional code maintenance commitments. ITK currently has about 60 such remote modules. It would be really nice if VTK developers embraced this idea, too, to attract more community contributions. vtkbool would be a perfect candidate for this, as it provides an essential feature that many people would expect to be part of VTK

If there is no chance for new VTK remote modules being accepted then @chir-set probably the only way is to build vtkbool as vtkAddon or VMTK (which is built as a VTK remote module using vtkAddon). Maybe @jcfr could give some advice for this.

6

I’m not sure how we could make any guarantees to the code that is:

  • not tested as part of CI (we have enough trouble keeping the code that lives in vtk/vtk.git to have stable pipelines)
  • not part of VTK’s regular contribution workflow
  • yet part of official wheel builds

VTK makes its install tree accessible to any project wanting to use VTK in a much more uniform way today than it used to. I still don’t understand the “but it is VTK code; it should build with VTK” argument. Should we vendor ParaView or build it as a remote module due to how much of VTK’s API it uses?

7

We don’t need to invent anything new, but we could do it similarly to ITK remote modules. Most ITK remote modules are tested and Python packages are generated using free github actions. Results could be reported to a central CDash server that is easily seen by VTK developers, but VTK developers would not be responsible for keeping those dashboards green.

There are different use cases:

  1. Building VTK remote modules with VTK: It would simplify life of VTK users in C++ who build their own VTK if some features that are essential but VTK core developers cannot afford to maintain (such as Boolean mesh operations, DICOM reader/writer, etc.) could be pulled in just by setting a CMake variable - without requiring any extra effort, without knowledge of VTK-style CMake modules, and without knowing what exact URL that repository is currently hosted at.
  2. Build VTK remote modules after VTK: It would simplify life of developers of VTK-based libraries if it was easy to build VTK-based libraries after VTK build is completed, to create shared libraries and Python wheels that are compatible VTK built and distributed by VTK core developers.

I know that 1 is feasible (because there are a few modules like that) and 2 is also feasible (e.g., vtkAddon by @jcfr) but neither user case seem to be endorsed or understood by the VTK developer team. VTK is enormous value provided for free for the community, so I cannot complain or demand anything. I just keep bringing up the importance of these use cases because they offer a very good return on investment for Kitware in medium/long term (free users may become paying customers; and community may be able to develop very valuable features that Kitware can benefit from).

8

RemoteModules are not part of VTK and the feature should be removed completely.

I agree with Ben here.
A project using VTK is responsible of keeping compatibility with VTK and so on, it is not VTK responsability.

The alternative is proper integration in VTK.

9

Kitware does not want to support VTK extensibility like they did for ITK? That is surprising considering Kitware lists VTK and ITK as major open-source toolkits that it leads development on.

10

I understand the desire to do it, but it just sounds very confused. My main question is: if a project wants to use a VTK Remote Module, how do I use it? Do I:

  • use find_package(VTK COMPONENTS RemoteModule)?
  • use find_package(RemoteModule)?
  • try both and hope something comes back from one of them?

The first is what remote modules does. However, Linux distributions, Homebrew, vcpkg, Spack, etc. are not going to download code during the build (as remote modules do today), so those paths are dead-ends. The second is what I would expect, but VTK isn’t going to learn how to make these things make their own export sets and Python packages. It’d just be easier to import the code and stick a “community maintained” label somewhere (as we effectively do[1] with, say, MinGW support).

As an analogy, why is VTK so different that users expect to be able to add their code to the VTK build? Should we go as Qt to support embedding VTK’s Qt support into their build? Or our HDF5 routines to the HDF5 project? Why is VTK so special that consuming code needs to be added to the VTK build directly?

Now, if you want to argue that VTK is still complex to use at this level…that’s hard to argue against. But we can look at supporting a “simple” API for these use cases. I know there’s a pile of example code we can look at to try and figure out a common denominator and provide that as a vtkModuleEasyMacros.cmake CMake API or something.

  1. Well, “effective” is doing a lot of work here; it may be that the sign is on a door in the basement guarded by a tiger. But that has been stated when MinGW questions come in: patches welcome, just keep it tidy and don’t break anything else. ↩︎

11

ITK and VTK does not have the same goals nor they have the same reach.

VTK is packaged on all distributions, ITK package is mainly on pip.
VTK is C++ with python wrapping, ITK, despite its C++ root, is more python than C++ if I’m not mistaken.

If a project want to extend VTK, they can simply find_package(VTK) and ship it the way they want, eg by pushing a wheel to pip.

You can look at vtk-ci-example or GitHub - f3d-app/f3d: Fast and minimalist 3D viewer.

Also I fully agree with @ben.boeckel again.