[vtk-developers] New module system preview

[Ben Boeckel]

On Mon, Oct 29, 2018 at 10:57:10 -0700, Bill Lorensen wrote:
> Will I be able to support both old and new?

As a consumer of modules is much easier than as a module. The variable
names which control things are completely different (now "namespaced"
via naming conventions). `find_package(VTK)` is similar as long as
`VTK_LIBRARIES` was used and components are specified, but the old
module's CMake API is gone.

Old "is X enabled" detection (though this shouldn't be necessary in
general[1]):

```cmake
if (Module_X)
```

New:

```cmake
if (TARGET X)
```

But, the module names are also different now in the new VTK as well, so
that makes consuming harder (though predictable).

Building a library used to be:

```cmake
vtk_module_library(X ${srcs})
```

and now has a much richer API:

```cmake
vtk_module_add_module(X
  SOURCES ${srcs}
  HEADERS ${headers}
  PRIVATE_HEADERS ${private_headers})
```

though there is also `CLASSES` which does the de-facto standard
`.cxx`/`.h` pairing for `SOURCES` and `HEADERS` automatically. In
addition to the ineffectiveness of `target_*` functions on module names
due to the kits implementation, making a module which supports both APIs
is not going to be trivial.

--Ben

[1]Optional dependencies now pass `-DVTK_MODULE_ENABLE_X=` as 1 or 0 if
available where `X` is a "safe" name for the module (basically `::`
replaced by `_`). This is to promote `#if` rather than `#ifdef` usage
for optional dependency detection in C++ code which triggers errors if
present in public headers (though in consuming targets) and also
triggers warnings if the optional dependency is removed or made
non-optional (because the define is no longer present).