gnikit
October 28, 2025, 7:25am
1
Hey guys, I wanted to ask if Kitware/VTK would consider/has considered adding a VTK recipe on Conan 2.0: C and C++ Open Source Package Manager . There might be good reasons as to why you haven’t done so already, but nonetheless I thought I would ask since I need to use VTK on a conan project and there doesn’t seem to be a great way of doing so in conan, except from writing my own recipe (which I did).
FYI there is a recipe on GitHub but not on the conan registry, but it is slightly incomplete/outdated see .
This post is more to spark a discussion on the subject and gather the community’s thoughts.
mwestphal
October 28, 2025, 7:43am
2
VTK maintainers are not packagers (apart the python wheel obviously)
But you definitely can add and maintain a conan recipe for VTK if you want to!
1 Like
Hello,
I have a full-fledged working Conan 2 recipe for VTK 9.3.1 here gammaray/conan2_recipes/vtk/9.3.1 at build_with_conan · PauloCarvalhoRJ/gammaray · GitHub . Feel free to use it, though I recommend reviewing the configuration part (the generate() callback) and the Qt dependency.
best,
PC
1 Like
gnikit
October 31, 2025, 7:24am
4
Fair, I will find some time in the coming weeks to upload it to conan centre. I would be more than happy if some of the VTK maintainers chimed in the PR for quality assurance (but also security).
Awesome, thanks a lot! Surprisingly my recipe looks awfully similar
1 Like
nbeck
November 13, 2025, 12:41pm
6
Just for reference, there is a closed PR for a VTK recipe
master ← valgur:new/vtk
opened 02:55PM - 03 Aug 24 UTC
### Summary
Changes to recipe: **vtk/9.3.1**
### Motivation
The Visualizat… ion 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
[](https://repology.org/project/vtk/versions)
### 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](https://gitlab.kitware.com/vtk/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:
- #18980
- #22360
- #23233
- #21296
- #21138
- #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. :heart:
### 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](https://gist.github.com/valgur/5404243903810bc1e92a2c12a2202e5e/raw/15acfab05c00351075395be41c971632311ba717/vtk_full_static_build.log)
- [shared](https://gist.github.com/valgur/5404243903810bc1e92a2c12a2202e5e/raw/15acfab05c00351075395be41c971632311ba717/vtk_full_shared_build.log)
- All external dependencies disabled:
- [static](https://gist.githubusercontent.com/valgur/5404243903810bc1e92a2c12a2202e5e/raw/15acfab05c00351075395be41c971632311ba717/vtk_minimal_static_build.log)
- [shared](https://gist.github.com/valgur/5404243903810bc1e92a2c12a2202e5e/raw/15acfab05c00351075395be41c971632311ba717/vtk_minimal_shared_build.log)
Build times are:
- minimal - 6 minutes
- default - 15 minutes
- full - 17 minutes
---
- [x] Read the [contributing guidelines](https://github.com/conan-io/conan-center-index/blob/master/CONTRIBUTING.md)
- [x] Checked that this PR is not a duplicate: [list of PRs by recipe](https://github.com/conan-io/conan-center-index/discussions/24240)
- [x] Tested locally with at least one configuration using a recent version of Conan
The same recipe can be found in GitHub - valgur/conan-center-index: An actively maintained fork of ConanCenter with an emphasis on CV, ML and robotics capabilities on edge devices
