vtk: new recipe

[valgur]

Summary

Changes to recipe: vtk/9.3.1

Motivation

The Visualization Toolkit (VTK) is open source software for manipulating and displaying scientific data. It comes with state-of-the-art tools for 3D rendering, a suite of widgets for 3D interaction, and extensive 2D plotting capability.

https://vtk.org/
https://gitlab.kitware.com/vtk/vtk

Details

Continues from #10776 by @paulharris with significant rewrites to tame the scope and complexity to more manageable levels. The project packages around 200 components and has about 70 dependencies (of which 56 are currently provided via Conan, 130 with transitive deps).

• I dropped the full YES/WANT/DONT_WANT/NO dependency resolution, which was complex enough to warrant a suite of unit tests, imo, and replaced it with a simpler alternative, which works well enough as long as the user sticks to only YES/NO choices.
• Module groups and kits are not supported. Kits "compile VTK into a smaller set of libraries" and "can be useful on platforms where VTK takes a long time to launch due to expensive disk access." Realistically, I would say supporting kits does not provide much value when static library output is available. The consumer is free to link the hundreds of modules down into a single executable if the number of shared libraries becomes a performance concern.
• Every module that can be built with the given set of external deps is built. Alternatively, want_all_modules can be set to False to build only the core modules and a specific subset of modules (and their internal dependencies) selected by the user instead.
• I expect the consumer to take care to link only against the relevant set of modules, since linking everything would be very unadvisable for this library. No catch-all VTK::VTK CMake target is exported for that reason (which matches the project's behavior). Instead, a poison target is included to prohibit the use of the aggregate vtk::vtk target when all modules are being built by default.
• The Conan component definition is almost fully dynamic to cope with the up to 200 total components exported by the project. The process is:
  1. Gather all CMake targets defined by CMakeDeps into a map of CMake->Conan targets and store it for later use.
  2. Parse the installed VTK-targets.cmake file for CMake targets and their properties. This provides the list of actually exported targets, whether they are real or interface ones, a list of internal and external public CMake target dependencies, system libs, frameworks and preprocessor defines.
  3. Parse the module.json build output to get the list of private dependencies for each component and some extra implementable/implements metadata for autoinit header generation.
  4. Generate autoinit headers required for static factory components defined in other modules to work. This is normally done in the project's CMake modules. The recipe implements a modified version that works for non-CMake generators as well. See the additional description in the code for more details.
  5. Map the CMake targets to Conan targets and store the component metadata in a JSON file in the package folder for the binary package.
  6. Apply the defined components in package_info() and add the private external dependencies that are not covered by the modules.json file (which itself is derived from the module.vtk files in the project).
• All external dependencies that are available on CCI are supported and work. At least on x86_64 Linux. I have not yet tested on other platforms.
• I did not add support for Python and Java wrappers or Python components in general.
• The recipe includes a Python script to generate the options/<version>.json files with ./update_options.py <vtk-source-location>. A --dump-metadata flag can be used to dump the metadata gathered from the module.vtk files as JSON instead, which provides a good overview of all modules and should be useful for diffing the metadata for changes for new releases. Keep in mind that many external dependencies are not listed as VTK modules, though, and are accessed directly through a find_package() wrapper.

TODO:

• Add a recipe for VTK-m, which is basically a CUDA/HIP etc accelerated backend for VTK.

Here's a list of related PRs for optional dependencies that are currently missing from CCI:

• openmpi: migrate to Conan v2 #18980
• openmp/system: new recipe #22360
• gdal: add v3.9.0, fix a CMake bug, bump deps #23233
• pdal: migrate to Conan v2, bump to v2.6.0, unvendor all available packages #21296
• openslide: new recipe #21138
• dawn: new recipe #24735 - although the support in the project is still very preliminary and broken

To conclude, I would like to thank @paulharris for the very hard work on the recipe. It was tremendously helpful, even if much of it got rewritten beyond recognition. ❤️

Build logs

All logs are for GCC 11 on x86_64 Linux.

• All external dependencies enabled (including the ones not yet available on CCI):
  • static
  • shared
• All external dependencies disabled:
  • static
  • shared

Build times are:

• minimal - 6 minutes
• default - 15 minutes
• full - 17 minutes

---

• Read the contributing guidelines
• Checked that this PR is not a duplicate: list of PRs by recipe
• Tested locally with at least one configuration using a recent version of Conan

[paulharris]

Nice to see some action, but just so you know, I'm using my VTK recipe in production and its working well.

I like the sound of the poison target, and it is interesting that you are parsing the cmake target file.

Looking forward to seeing it progress further!

[conan-center-bot]

Conan v1 pipeline ✔️

All green in build 16 (69b4bd23c4901abc31e482aece850546ef4fdf83):

• vtk/9.3.1:
  All packages built successfully! (All logs)