# Building vtkbool as a remote module does not seem to complete.
**URL:** https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043
**Category:** Support
**Created:** [September 14, 2025, 10:35am UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043 "2025-09-14T10:35:30Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@chir-set](https://discourse.vtk.org/u/chir-set)
#### Post date: [September 14, 2025, 10:35am UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/1 "2025-09-14T10:35:31Z")
Hello,
I am trying to build [vtkbool](https://github.com/zippy84/vtkbool/) as a remote module of VTK 9.5 within Slicer’s build tree.
This `vkbool.remote.cmake` file is used:
```auto
#
# 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:
```auto
-DVTK_MODULE_ENABLE_VTK_vtkbool:STRING=WANT
-DVTKBOOL_PARAVIEW:BOOL=OFF
```
The `CMakeCache.txt` file contains:
```auto
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.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 14, 2025, 6:46pm UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/2 "2025-09-14T18:46:52Z")
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.
---
### Author:  [@chir-set](https://discourse.vtk.org/u/chir-set)
#### Post date: [September 14, 2025, 8:36pm UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/3 "2025-09-14T20:36:50Z")
> [@ben.boeckel](#):
>
> a legacy support mechanism. No remote modules are regularly tested
Thank you very much, this is a valuable information, there is no reason to persist in a dead end then.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 15, 2025, 12:03am UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/4 "2025-09-15T00:03:41Z")
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`).
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [September 15, 2025, 6:24am UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/5 "2025-09-15T06:24:00Z")
> [@ben.boeckel](#):
>
> 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
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](https://github.com/InsightSoftwareConsortium/ITK/tree/main/Modules/Remote). 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](https://github.com/Slicer/vtkAddon) or [VMTK](https://github.com/vmtk/vmtk) (which is built as a VTK remote module using vtkAddon). Maybe @jcfr could give some advice for this.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 15, 2025, 5:35pm UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/6 "2025-09-15T17:35:54Z")
> [@lassoan](#):
>
> without forcing library core developers to take on additional code maintenance commitments.
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?
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [September 15, 2025, 8:18pm UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/7 "2025-09-15T20:18:43Z")
> [@ben.boeckel](#):
>
> I’m not sure how we could make any guarantees
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.
> [@ben.boeckel](#):
>
> 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?
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](https://github.com/Slicer/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).
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [September 16, 2025, 6:10am UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/8 "2025-09-16T06:10:52Z")
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.
---
### Author:  [@jamesobutler](https://discourse.vtk.org/u/jamesobutler)
#### Post date: [September 16, 2025, 11:23pm UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/9 "2025-09-16T23:23:32Z")
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.
> **[ITK/Policy and Procedures for Adding Remote Modules](https://insightsoftwareconsortium.github.io/ITKWikiArchive/Wiki/ITK/Policy_and_Procedures_for_Adding_Remote_Modules/)**
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 17, 2025, 2:16am UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/10 "2025-09-17T02:16:32Z")
> [@lassoan](#):
>
> I know that 1 is feasible (because there are a few modules like that) and 2 is also feasible (e.g., [vtkAddon](https://github.com/Slicer/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).
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.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [September 17, 2025, 7:10am UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/11 "2025-09-17T07:10:57Z")
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](https://gitlab.kitware.com/vtk/vtk-ci-example%5C) or [GitHub - f3d-app/f3d: Fast and minimalist 3D viewer.](https://github.com/f3d-app/f3d)
Also I fully agree with @ben.boeckel again.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 17, 2025, 1:30pm UTC](https://discourse.vtk.org/t/building-vtkbool-as-a-remote-module-does-not-seem-to-complete/16043/12 "2025-09-17T13:30:18Z")
Note that PyPI is difficult because there’s no pathway to use libraries from other wheels that are directly linked. There is ongoing discussion about it in the Python ecosystem, but it is not an easy problem to solve. You _can_ make wheels, but either they’ll ship a copy of VTK themselves or be disallowed on PyPI due to needing shared libraries not in the blessed list for each platform.