cmake find_package (VTK)

Support
1

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,

2

Here is how we support old and new in the VTKExamples project:
https://lorensen.github.io/VTKExamples/site/Cxx/GeometricObjects/Dodecahedron/#cmakeliststxt

Bill

3

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.

4

8.9 is not related yet. Perhaps it will be released as 9.0?

5

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(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.

6

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 which I objected to when proposed for ParaView 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.

7

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.

8

With respect to API incompatibilities you can do something like this in your code:

#include <vtkVersion.h>
//...

#if VTK_MAJOR_VERSION > 8 || VTK_MAJOR_VERSION == 8 && VTK_MINOR_VERSION >= 90
// ...
#ielse
// ...
#endif
9

We should really have a macro for this. Something that would allow:

#if VTK_VERSION < VTK_MAKE_VERSION(8, 90, 0)
#else
#endif
10

https://gitlab.kitware.com/vtk/vtk/merge_requests/5368

11

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.

12

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.

13

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