# cmake find\_package (VTK)
**URL:** https://discourse.vtk.org/t/cmake-find-package-vtk/663
**Category:** Support
**Created:** [April 2, 2019, 4:50pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663 "2019-04-02T16:50:22Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@tirons](https://discourse.vtk.org/u/tirons)
#### Post date: [April 2, 2019, 4:50pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/1 "2019-04-02T16:50:23Z")
Hi, I’m not sure if this is a CMake or a VTK question…apologies if this is the wrong place, but I think the behaviour I’m seeing stems from VTK’s FindVTK.cmake file.
My C++ project has an optional VTK dependency, and compilation of VTK is sufficiently onerous that I don’t want to impose that on users. As such, I am using the find\_package:
`find_package (VTK 8.2)`
This works well most of the time, except for a few users who have the development version of VTK installed (e.g. 8.9.0). Unfortunately, 8.9.0 is not API compatible with 8.2! I don’t want to have to try and support a moving target of a development VTK install. It is my opinion that the find\_VTK.cmake should be updated to reflect that the development branch is not API compatible with the current releases.
Alternatively, is there a way to do something like
`find_package(VTK 8 <= 8.2)`? This isn’t valid CMake syntax, but I think it’s clear what I am trying to do.
Alternatively, I can whitelist release versions, and search for them explicitly,
`find_package (VTK 8.2.0 EXACT )`
`if (NOT VTK_FOUND)`
`find_package( VTK 8.1.2 EXACT )`
`endif()`
But this seems prone to having issues and will require more maintenance. Thanks for any ideas,
---
### Author:  [@lorensen](https://discourse.vtk.org/u/lorensen)
#### Post date: [April 2, 2019, 6:03pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/2 "2019-04-02T18:03:51Z")
Here is how we support old and new in the VTKExamples project:
[https://lorensen.github.io/VTKExamples/site/Cxx/GeometricObjects/Dodecahedron/#cmakeliststxt](https://lorensen.github.io/VTKExamples/site/Cxx/GeometricObjects/Dodecahedron/#cmakeliststxt)
Bill
---
### Author:  [@tirons](https://discourse.vtk.org/u/tirons)
#### Post date: [April 2, 2019, 6:38pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/3 "2019-04-02T18:38:32Z")
Thanks so much Bill (wow!). This is a more graceful CMake solution for sure. I certainly don’t like the whitelist idea.
However, it doesn’t help with API incompatibilities. To adopt this approach, I would need to add include guards within my code to deal with differences in 8.9 and 8.2. In particular the HyperTree class is wildly different.
I suppose that is what I find somewhat confusing, in my mind changes which break the API should not have the same major version, IMHO.
Thanks again, this was helpful.
---
### Author:  [@lorensen](https://discourse.vtk.org/u/lorensen)
#### Post date: [April 2, 2019, 7:47pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/4 "2019-04-02T19:47:45Z")
8.9 is not related yet. Perhaps it will be released as 9.0?
---
### Author:  [@tirons](https://discourse.vtk.org/u/tirons)
#### Post date: [April 2, 2019, 8:46pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/5 "2019-04-02T20:46:32Z")
Thanks again Bill. And truly, thanks for considering this with your other thread. From my limited perspective I agree 8.90 should be a candidate for a major version bump.
I’m hitting this problem because a sysadmin installed 8.90 across a cluster some of my users use. (Apparently the sysadmin was hitting installation errors on 8.20…I don’t know the details.)
Anyhow, CMake treats the 8.90 branch like any other 8.x branch. When I run [find\_package](https://cmake.org/cmake/help/v3.14/command/find_package.html)(VTK 8.2.0), I was expecting `VTK_VERSION_EXACT` and `VTK_VERSION_COMPATIBLE` to get set. Then I could use these to test whether or not the version that CMake found was going to be compatible with my code targeting 8.2.0. These variables are not getting set, but I don’t know where responsibility for this lies. I can of course check compatibility myself using `VTK_VERSION` like you showed in your example. I’m sated and will take that approach, thanks. The CMake documentation had made it seem as if this should happen automagically, hence my confusion.
But for posterity, I was surprised because even though 8.90 is not released, it’s behaving as if it is a released variant of VTK 8.x according to CMake. Unless I’m doing something wrong, which is entirely possible.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [April 3, 2019, 8:15pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/6 "2019-04-03T20:15:35Z")
> From my limited perspective I agree 8.90 should be a candidate for a major version bump.
It will almost certainly be 9.0 upon release. But, we don’t want to call it 9.x yet because otherwise in-development code will be detected as 9.0.
> Anyhow, CMake treats the 8.90 branch like any other 8.x branch
This is because of [this change](https://gitlab.kitware.com/vtk/vtk/merge_requests/5203) which I objected to when proposed [for ParaView](https://gitlab.kitware.com/paraview/paraview/merge_requests/3016) and the rationale described there applies to VTK as well. Please file an issue referencing the VTK merge request and Cc the MR author there for discussion.
> But for posterity, I was surprised because even though 8.90 is not released, it’s behaving as if it is a released variant of VTK 8.x according to CMake.
There’s no good way to indicate “is released” in a version number without pre-release versioning which isn’t really standard. The closest we could get is calling it `9.00.0` which is less than `9.0.0` in CMake, but is “only” extremely confusing to everyone else.
---
### Author:  [@lorensen](https://discourse.vtk.org/u/lorensen)
#### Post date: [April 3, 2019, 9:50pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/7 "2019-04-03T21:50:25Z")
I think using the tag x.90 is a good development version that will become x+1.0.0.
For minor versions, x.90 would be released as x.y+1.0
Maybe we should document this naming convention somewhere.
---
### Author:  [@amaclean](https://discourse.vtk.org/u/amaclean)
#### Post date: [April 3, 2019, 11:02pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/8 "2019-04-03T23:02:52Z")
With respect to API incompatibilities you can do something like this in your code:
```auto
#include
//...
#if VTK_MAJOR_VERSION > 8 || VTK_MAJOR_VERSION == 8 && VTK_MINOR_VERSION >= 90
// ...
#ielse
// ...
#endif
```
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [April 4, 2019, 12:12pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/9 "2019-04-04T12:12:54Z")
We should really have a macro for this. Something that would allow:
```auto
#if VTK_VERSION < VTK_MAKE_VERSION(8, 90, 0)
#else
#endif
```
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [April 4, 2019, 12:17pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/10 "2019-04-04T12:17:56Z")
[https://gitlab.kitware.com/vtk/vtk/merge\_requests/5368](https://gitlab.kitware.com/vtk/vtk/merge_requests/5368)
---
### Author:  [@tirons](https://discourse.vtk.org/u/tirons)
#### Post date: [April 4, 2019, 5:59pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/11 "2019-04-04T17:59:07Z")
I don’t totally follow the logic that you would have to have pre-release versioning like `9.00.0`? I suppose if it’s policy to have the first release be x.0.0 then that would be true.
VTK is obviously a very successful project, and I’m not trying to suggest a change in the development cycle. I now have a little more insight into the versioning, and will just keep track of the releases and make less assumptions about the version chronology.
Regardless, the proposed macro would be a helpful addition.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [April 4, 2019, 7:26pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/12 "2019-04-04T19:26:00Z")
Well, the problem is that one doesn’t always know that the next version is going to be a major bump (here, we do, hence the bump all the way to 8.90). `master` could have been 8.3 and then before release bumped to be 9.0. If we had better release planning, that could be considered.
---
### Author:  [@eric](https://discourse.vtk.org/u/eric)
#### Post date: [April 21, 2021, 6:05pm UTC](https://discourse.vtk.org/t/cmake-find-package-vtk/663/13 "2021-04-21T18:05:39Z")
I don’t mean to dredge up a dead post. I found this thread through google.
The link posted by Bill Lorensen is no longer available due to circumstances.
For posterity, this is the new link:
[https://kitware.github.io/vtk-examples/site/Cxx/GeometricObjects/Dodecahedron/#cmakeliststxt](https://kitware.github.io/vtk-examples/site/Cxx/GeometricObjects/Dodecahedron/#cmakeliststxt)