[Insight-developers] ConceptCheck & Wrapping : ITK 3.4 Update

[Brad King]

Peter Cech wrote:
> Turning off whole class of constructs on compile time works for backward
> compatibility, but if you develop new code in parallel, concept check at
> right place might save you a lot of time (been there). What about
> version-targeted backward compatibility instead?
> 
> What I mean is enabling backward-compatible or backward-incompatible fix
> depending on user choice. For the current situation it would look like:
> 
> - If ITK_3_2_COMPATIBILITY <= VERSION(3,2), a backward compatible bugfix
>   (runtime error reporting) is enabled.
> 
> - If ITK_3_2_COMPATIBILITY > VERSION(3,2), a backward incompatible
>   bugfix (concept check) is enabled.
> 
> What do you think about it?

Good idea!

This is the approach CMake uses with the "CMAKE_BACKWARDS_COMPATIBILITY"
variable.  It may be set by the user to a value smaller than the current
version of CMake.  Then when a breaking change is made we set things up
to check the value of this variable.  The old behavior is maintained if
the value of the variable is low enough.

In CMake this variable defaults to the value of the current version for
a new build tree.  Error messages that are related to the breaking
change include the version number to which CMAKE_BACKWARDS_COMPATIBILITY
must be set to disable the message.  This has the advantage that new
development and new projects will always get the most modern behavior
while still allowing existing code to work.  Existing build trees
created by older versions of CMake will already have the variable set to
the older version in the cache, so users with existing build trees do
not need to touch anything when they upgrade.

We can probably design a similar solution for ITK.  However the trick is
that the backwards compatibility level required may be different for
each project using a single ITK build.  Perhaps the build of ITK should
have a CMake option specifying the oldest level of compatibility to
support (for changes in the compiled binaries).  Then a preprocessor
definition can be used to adjust concept checking rules.  Whenever a
concept check is added it is put inside a compatibility test against the
current version.  A macro can package up the test to make it readable:

#if !ITK_COMPATIBILITY(3, 2)
  // Concept check here...
#endif

Next we need to find a way to get the compatibility version information
into the concept check error message.  It shouldn't be too hard to
encode a type describing the version of the check.

-Brad