Hi Michael Sorry that this is causing so much frustration. Unfortunately, ITK and VTK keep changing fairly rapidly, so code that compiles versus a certain version no longer compiles against older or later versions.
Here is a table of version compatibility between versions of ITK-SNAP, ITK, VTK and Qt. http://www.itksnap.org/pmwiki/pmwiki.php?n=Documentation.BuildingITK-SNAP. Does this help? Thanks Paul On Wed, Oct 15, 2014 at 1:00 PM, Michael Hanke <m...@debian.org> wrote: > Hi, > > I am reviving this old thread in order to bring it to an end. Everyone > who has expressed interest and/or frustration in the past is in CC > (incl. the relevant bug). > > Over the past month (or rather year) I have repeatedly tried to update > the itksnap package, and today I am giving up. ITK-SNAP has extremely > tight versioned dependencies on ITK and VTK. Making it work with any > current ITK version in Debian seems to require a lucky roll of the dice > (that would not come for me). As of today, neither the current stable > 3.2, nor the master branch head compiles in sid. At least for the first > I am pretty sure a version mismatch is the case (see e.g. [1]). > The actual reasons for FTBFS change over time, but the failure rate is > close to 100% for my attempts. > > My personal conclusion is that it makes no sense to maintain an itksnap > package independently of ITK. > > The package has a popcon score of 241 -- rather solid for a special > interest package of this kind (about half of what ITK3 had in its > prime). It would be a shame to see it go away. On the other hand > dragging an outdated version along forever is not an option. > > And to make it very clear: ITK-SNAP is a solid piece of software that I > have enjoyed using (and still do). The problem is solely a ridiculously > complex software interdependency problem, that makes long-term package > maintenance a nightmare. > > I have tagged the bug with "help". I see no reason to remove itksnap > from jessie, because this old version does what it was intended to do. > But for the next round we either need to find a better home, or we > should let it go. > > Cheers, > > Michael > > [1] https://groups.google.com/forum/#!topic/itksnap-users/2byPxMTS3Wo > > > > -- > Michael Hanke > http://mih.voxindeserto.de > > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
