[Insight-developers] CMake variable name inconsistencies

[Williams, Norman K]

I was unaware until I was trying to evaluate this question how extensive
the use of ITKV3_COMPATIBILITY is.


This is a concern, since it complicates migration, creating 3 types of
migration issues:

1. Things an end user has no choice but to change to accommodate
2. Things that will continue to work more or less as they did in V3 with
ITKV3_COMPATIBILITY turned on
3. Things that work more or less the same as V3.

Case #2 is very problematic because it is a way in which the ITK
consortium is NOT making a clean break.  In essence, there's a collection
of sub-optimal behaviors we'll be saddled with maintaining at least until
ITKV5.  And it adds a dimension to the configuration phase space.  Are we
going to want to preface every post answering a question on ITK-users with
'do you have ITKV3_COMPATIBILITY turned on?'

Of course, getting rid of it entirely at this point will probably make
ITK4 stop working in Slicer.

I don't have a solution for this,  it just was making my stomach churn
this morning.

On 10/3/11 8:18 AM, "Brad King" <brad.king at kitware.com> wrote:

>
>Do we want to support ITKV3_COMPATIBILITY without the module?  Should
>we simplify the interface by just forcing the module on with that option?
>We already do that for ITK_USE_REVIEW.
>
>-Brad



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________