[Insight-developers] ITKImageFunction dependecy in Transform

[Gaëtan Lehmann]

Le 19 août 11 à 19:08, M Stauffer (V) a écrit :

>>> This issue has popped up again, see below...
>>>
>>>>>>>> In rebasing the Transform changes patch set onto the latest
>>>>>>> itk master, I've
>>>>>>>> got a dependency problem. DeformationFieldTransform
>>>>>>>> includes itkVectorLinearInterpolateImageFunction.h, which is
>>>>>>>> in ITKImageFunction. But adding this to
>>>>>>> Transform/itk-module.cmake causes a
>>>>>>>> circular dependency. Any suggestions? I don't know how to
>>>>>>> handle this.
>>>>>>>
>>>>>>> That is a difficult problem.  Moving DeformationFieldTransform  
>>>>>>> to
>>>>>>> ITKImageFunction would probably not be appropriate.  Is it
>>>>> possible to
>>>>>>> use a C++ forward declaration for
>>>>>>> VectorLinearInterpolateImageFunction?  I assume that any module
>>>>>>> depending on ITKTransform is also likely to depend on
>>>>> ITKImageFunction
>>>>>>> anyway.
>>>>>>
>>>>>> OK, a forward declare works. Of course I have to declare
>>>> the template
>>>>>> parrameters along with the forward declaration so it's a
>>>>> little messy in
>>>>>> that it will need changing if the
>>>>> VectorLinearInterpolateImageFunction
>>>>>> template parameters change. Although if the class template
>>>>> pararmeters
>>>>>> change, lots of classes will change so I figure that's not a real
>>>>>> problem. So is forward-declaration like this ok in the ITK style?
>>>>>
>>>>> Great.
>>>>>
>>>>> ITK has very strong backwards compatibility, changes to the API  
>>>>> like
>>>>> that will not take place after the ITKv4 release, and changes that
>>>>> break compatibility during ITKv4 need to have migration documents.
>>>>> http://www.vtk.org/Wiki/ITK_Release_4/Users_Migration_Guide
>>>>>
>>>>> Forward declaration is not typical ITK style.  However, if it is
>>>>> documented with a comment in the code explaining the need to break
>>>>> circular dependency, it could be OK.
>>>>>
>>>
>>> It turns out this has worked only because the cxx files where
>>> itkDisplacementTransform.h is included also include
>>> itkVectorInterpolateImageFunction.h and
>>> itkVectorLinearIntepolateImageFunction.h. Of course these have to be
>>> included somewhere for the forward-declare to work, but this
>> seems bad
>>> for the use to have to include these other two headers separately.
>>>
>>> Looking at Core/ImageFunction, the only class that includes
>> Transform is
>>> RayCastInterpolateImageFunction. Would it make sense to move this to
>>> another module so that ImageFunction needn't depend on Transform?
>>>
>>
>> Good detective work.  Maybe move RayCastInterpolateImageFunction to
>> Core/Common instead of the forward declare?
>>
>> Thanks,
>> Matt
>
> OK I've tried that and it works. I removed ITKTransform as a  
> dependency
> of ITKImageFunction, and added ITKImageFunction as a dependency of
> ITKTransform. I moved RayCastInterpolateImageFunction to Core/Common.
>

itkRayCastInterpolateImageFunction.h still includes itkTransform.h,  
right?

If that's the case, it can't be moved to Core/Common, because  
itkTransform.h is in ITKTransforms which is not a dependency of  
ITKCommon.

> What's the protocol for going ahead with a move like this? Doesn't  
> seem
> like much of a change since RayCastInterpolateImageFunction is still  
> in
> Core. Matt, do you feel ok giving the final go-ahead for this, or do  
> we
> get other approval too?
>

Module groups don't have much meaning when dealing dependencies.

This problem is preventing wrapping to build - the forward declaration  
is not enough, the headers must be included - it would be fine to find  
a solution.

In that case I guess the only options are:

   a. move RayCastInterpolateImageFunction to ITKTransforms

   b. move DeformationFieldTransform to ITKImageFunction

   c. move RayCastInterpolateImageFunction to another module which  
depends on both ITKTransforms and ITKImageFunction. If no current  
module fit for that task, then a new one should be created.

   d. move DeformationFieldTransform to another module which depends  
on both ITKTransforms and ITKImageFunction. If no current module fit  
for that task, then a new one should be created.

And of course adjust the module dependencies.

I think my preference would go for c.

Regards,

Gaëtan

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://mima2.jouy.inra.fr  http://www.itk.org
http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110821/d17e3eea/attachment.pgp>