[vtk-developers] New module system preview

[Ben Boeckel]

On Mon, Oct 29, 2018 at 15:45:36 -0400, David Thompson wrote:
> Even if it is two passes, why can't it be done from CMakeLists.txt?
> The second pass just adds library dependencies, header search paths,
> other target properties, and install rules, correct? Can't that be
> done any time after the libraries are declared?

First, the concept would require `target_link_libraries` support for
out-of-directory targets. That can't be done without 3.13.0 (still in
its rc cycle). It also means that we wouldn't be able to say "no" to
building some modules without somehow "undo"ing an `add_library` call.

Second, it's an ease-of-use problem. Say I don't have MPI on my machine.
I can't `add_subdirectory` *any* directory which requires `VTK::mpi`
because that module can't exist on my machine. How is the module system
supposed to know what directories can and cannot be included? If it is
`CMakeLists.txt` via `add_subdirectory` or `include`, the structure
would end up like:

```cmake
if (vtk_module_phase STREQUAL "scan")
  vtk_module_declare(<vtk.module args>)
elseif (vtk_module_phase STREQUAL "build")
  vtk_module_add_module(...)
endif ()
```

Third, part of the point of `vtk.module` is so that there *is no logic*
allowed. Making it part of `CMakeLists.txt` makes it much harder to
enforce this. Though this does make me think that we could stuff the
`vtk.module` contents in a comment header of the associated
`CMakeLists.txt`. That might be worth looking into. I'll add a TODO item
for it.

Towards the third point, it was a mistake to allow
`${VTK_RENDERING_BACKEND}` in the old module system's `module.cmake`
files. VTK should have supported building OpenGL1 *and* OpenGL2 backends
at the same time with executables using the object factory mechanism to
decide which one gets used. It also meant that some modules had classes
popping in and out of existence depending on other flags (e.g.,
`vtkIOMovie` contains `vtkOggTheoraWriter` depending on whether or not
`vtkoggtheora` is available…not something easy to have Just Work via
`find_package(VTK)` failing (the new module system now has a
`VTK::IOOggTheora` module for this class).

> It just feels like VTK and ParaView should be "best practices"
> examples. Your branch gets things a *lot* closer, but some twiddly
> details (the special .module/.kit files, no use of add_subdirectory,
> etc) get in the way of someone familiar with CMake but not these
> projects.

Unfortunately, things like kits, optional component building, complex
dependency graphs, etc. are not "common" and doing them via "best
practices" applicable to CMake projects in general isn't easy.

IMO, "best practices" would tell me that VTK should be many repositories
(or, many top-level builds at least) and each build has *no options* to
turn on or off bits of the build (modulo platform support and
deprecation). If one wants MPI support, go build the MPI subdirectory
and you get VTK MPI support.

Granted, there might be a top-level "enable these sections of code" flag
which runs all the subprojects like a superbuild, but I don't think the
downsides of the superbuild (i.e., ExternalProject) are ignorable for
projects with a developer and user community the size of VTK as-is.

--Ben