[vtk-developers] New module system preview

[Ben Boeckel]

Hi all,

I've gotten the new module system to a point that I'd like to open up
testing to other developers. It's not 100% complete (see the known
issues listing below), but it's pretty close. I'd highly recommend using
a new build tree for building the branch.

Notes for WIP things on the branch:

  - There's a hard-coded list of "don't build this" in CMakeLists.txt
    currently just for my convenience. Feel free to edit the
    `REJECT_MODULES` argument list as needed for your machine(s).

Overview of changes:

  - Instead of `module.cmake`, there are `vtk.module` and `vtk.kit`
    files. These are basically CMake argument lists, but no variable
    expansion is allowed. If there are optional dependencies, they must
    be private dependencies. Optional public dependencies indicate that
    a new module should be made instead.

  - Modules may now be "rejected" and never built. This turns off
    *dependent* modules. If a module is required and also has a rejected
    module as a dependency, an error occurs.

  - Minimum CMake is still 3.3, but kit support requires CMake 3.12+ for
    object library features.

  - There are no more `vtk_mpi_link` or `vtk_opengl_link` "magic"
    functions. Instead, just depend on the `VTK::mpi` and `VTK::opengl`
    modules.

  - Third party modules now declare whether they support external copies
    or not (i.e., no more useless `VTK_USE_SYSTEM_kwsys` variable). See
    the `ThirdParty` directory for various examples. Other third parties
    only support external copies (e.g., `VTK::mpi` and `VTK::opengl`).

  - Imported targets are now preferred for `find_package` callers. Third
    party packages warn about this usage, but others do not. There is
    also the `vtk_module_find_package` call which also adds required
    `find_package` calls to the `vtk-config.cmake` file for external
    consumers (only necessary when using imported targets).

  - Module names now look like `VTK::CommonCore`. This is a target name
    which can be used anywhere, within or outside of the VTK source
    tree. Non-module projects now do:

```cmake
# Find VTK.
find_package(VTK REQUIRED COMPONENTS CommonCore)
# Make two programs.
add_executable(myexe1 myexe1.c)
add_executable(myexe2 myexe2.c)
# Add include directories, link line, compile definitions, etc.
# necessary to use VTK::CommonCore.
target_link_libraries(myexe1 PRIVATE VTK::CommonCore)
target_link_libraries(myexe2 PRIVATE VTK::CommonCore)
# Add VTK_AUTOINIT defines to the targets.
vtk_module_autoinit(TARGETS myexe1 myexe2 MODULES VTK::CommonCore)
```

  - To add requirements to a module, the module system offers some
    functions in lieu of CMake's `target_*`. This is in order to
    properly support kits (the `CommonCore` target is just an
    `INTERFACE` library in this case and `PRIVATE` link libraries need
    copied onto the containing kit). The functions:
    * `vtk_module_compile_options`
    * `vtk_module_definitions`
    * `vtk_module_include`
    * `vtk_module_link`
    * `vtk_module_link_options` (depends on `target_link_options` in
      CMake 3.13+)

It is currently based on `master` as of a week ago, but I'll probably
rebase again this week.

Please file issues found with the branch on my fork of VTK:

    https://gitlab.kitware.com/ben.boeckel/vtk/issues

to make things easier to track. Since Gitlab doesn't support MRs between
sibling forks (yet), please attach patches to issues if you have a fix.

Known issues:

  - Running generated Java wrappers needs some attention. Missing
    symbols (from Java code?) happen when running the tests.
  - Windows support (there are some `:` characters left in filenames
    yet).

Unimplemented:

  - Remote modules (conceptually the same as before, but there are no
    remote modules that have been ported right now)
  - `OPTIONAL_PYTHON_LINK` magic keyword. This can now just be supported
    in the `VTK::Python` module, but has not been implemented.

Untested:

  - Multi-config generators (e.g., Xcode and Visual Studio).
  - Mobile device support.

Thanks,

--Ben