Thanks David, This is exactly the sort of things I was thinking of. I definitely agree that the IJ template package would benefit from community effort :)
Tom On Tue, Dec 4, 2012 at 11:06 PM, David Doria <[email protected]> wrote: > On Tue, Dec 4, 2012 at 4:45 PM, Tom Vercauteren <[email protected]> > wrote: >> Hi folks, >> >> I unfortunately have almost no time anymore to contribute to ITK. Yet, >> I wanted to start fiddling with ITK 4 (I know it has been out for >> quite some time already...) by cleaning up an old submission of mine >> that needs some TLC to compile seamlessly with ITK 3 and 4: >> http://hdl.handle.net/1926/510 >> >> I was happy to see that the code is now on github >> https://github.com/midas-journal/midas-journal-154 >> but I could not find anywhere in the Insight Journal documentation >> whether (and how) I could use this repository to update the >> submission. >> >> Then I started without any porting effort to compile my old code with >> ITK 4. I did not want to rely on any ITKv3Support mechanism as I >> didn't want my code not to be native ITK4 in the end (I still have bad >> memories about relying on Qt3Support a few years ago). >> >> I first stumbled into a compilation error in ImageCompare.cxx: >> #error For ITKv4 compatibility, use >> itk::Testing::ComparisonImageFilter instead of >> itk::DifferenceImageFilter >> >> Remembering that ImageCompare was part of the Insight Journal template >> package, I went back and re-downloaded the template package. >> Unfortunately, the template package has not been ported to ITK4 yet >> and the ImageCompare.cxx file is still the same as the old one I had. >> >> I could of course patch my local Insight Journal Template Package as >> well as my other files and when everything will work fine, I could >> also upload a new source package to the Insight Journal rather than >> using github but this doesn't sound quite right. Did I miss something >> or is it simply that the Insight Journal also needs some TLC to >> properly handle ITK4? >> >> That being said, are there any suggestions to handle seamlessly ITK 3 >> and 4 without imposition the use of ITKv3Support. I can see two >> options right now: >> 1) Pepper the code with #if ITK_VERSION >> 2) Have two distinct files, one for ITK3, one for ITK4 and let cmake >> choose which one to compile >> >> Sorry for the long email and thanks for all the efforts that have been >> made for ITK4 already. >> >> Tom > > I fixed a few of these things a while ago: > > 1) The use of itkDifferenceImageFilter which has been replaced by > itkTestingComparisonImageFilter. > 2) ::itk::OStringStream seems to now be simply std::ostringstream. > 3) I used the ${ITK_LIBRARIES} variable in the CMakeLists.txt.). > > I guess they still haven't been integrated. Perhaps since it is an open > access journal, things like this template tarball should also be made > publicly fixable (through Gerrit of course) so that they can be kept up to > date by the community even if there is no funding. > > I'll let someone else handle your question about easily supporting ITK3/4 :) > > David _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-developers
