[vtk-developers] New module system preview

[Ben Boeckel]

On Thu, Nov 08, 2018 at 13:15:32 -0700, David Gobbi wrote:
> Package managers like to be able to subdivide VTK into multiple packages.
> Being able to modularize the build itself, so that VTK can be built
> kit-by-kit
> instead of all at once, is a logical extension of the multiple package idea.
> If I recall correctly, the CI system for pypi was failing to build VTK due
> to
> timeouts (I'm not sure what the workaround was, I suspect that Prabhu
> built the wheels manually).

We could support that via another top-level `CMakeLists.txt` which only
builds specific modules. The main problem would be getting the installed
CMake files to all work together. In particular,
`find_package(VTK-prev-stage)` would need to be done in later stages
since multiple packages wouldn't be able to install to the same CMake
package. The installed VTK CMake package would be…not the same for
consumers of the package.

The best thing to do is probably to trim down what constitutes VTK
itself and move modules to external repositories.

> On a related note, we definitely want to be able to build remote modules
> against an installed VTK.  Currently my vtk-dicom remote module has two
> parallel sets of cmake logic: one for when it builds as a remote module, and
> another for when it builds against VTK binaries.  It would be nice if
> building
> a remote module externally "just worked".

The way I'd see this working best is:

    vtkdicom/CMakeLists.txt - standalone build
    vtkdicom/module/        - directory for the module
    vtkdicom/module/vtk.module
    vtkdicom/module/CMakeLists.txt

VTK wouldn't care about the top-level `CMakeLists.txt` at all. It would
find the module via the `vtk.module` file and module logic would just
build it as any other module (this is what ParaView does for its
VTK submodule).

--Ben