[vtk-developers] VTK_MAJOR_VERSION is no longer #define'ed

Brad King brad.king at kitware.com
Wed Apr 25 10:55:13 EDT 2012


On 4/25/2012 10:08 AM, Bill Lorensen wrote:
> I really do not want to turn VTK_LEGACY_REMOVE OFF. If enables much
> more than the new versioning.
>
> In the hundreds of examples I have converted to work with both VTK5
> and VTK6 I've used this pattern:
> #if VTK_MAJOR_VERSION<= 5
>    inputMapper->SetInput(inputPolyData);
> #else
>    inputMapper->SetInputData(inputPolyData);
> #endif
>
> I would like this code to work without having to add another #include.

If your goal is to write code that works with multiple versions of
VTK I don't think including a header with "Version" in its name
is too much to ask.

VTK_LEGACY_REMOVE=OFF exists to allow code that worked with older
VTK versions to work without modification.  This is such a case.

Reading code with conditionals like the above is not a great way
to learn VTK 5 or VTK 6.  If the purpose of the example is to
show how to write code that works with both versions, then sure
it should have the conditionals, but it can also include the
version header.  Otherwise the example should be clearly labeled
as "VTK 5" or "VTK 6".

This is a *major* version number bump.  It is a rare chance to
clean up goobers the require compatibility breakage to fix.

Note that a benefit of the new approach is that VTK_BUILD_VERSION
can get nightly granularity in C++ code.  Previously this only
existed at the CMake package level, and that was actually quite
inconsistent with the C++ macro.  IIRC it was not so long ago
that you brought up on the ITK list how wonderful this level of
version granularity is for applications to test.

-Brad



More information about the vtk-developers mailing list