Hi,
On Wed, May 27, 2009 at 10:09:40AM -0500, John Harwell wrote:
> Steve,
>
> What is the error you are receiving when trying to compile Caret?
>
> Problems with newer versions of VTK are not unusual and I continue to
> use 5.0.2. Plus, I have never been fond of cmake. In any case, I
> have made a copy of VTK-5.0.2 available at
> "http://brainvis.wustl.edu/wiki_linked_files/caret_files/vtk-5.0.2.zip
> ". There is now a link to this version of VTK on from
> "http://brainvis.wustl.edu/CaretHelpAccount/caret5_help/source_code/source_code.html
>
> ". My desire is to remove VTK from Caret but VTK provides some
> complex algorithms (polygon decimation and surface reconstruction)
> that we need.
>
> The bug report (http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=518640
> ) was probably resolved by a Caret user (Michael Hanke) that builds
> Caret for Debian Linux.
Unfortunately not.
I could not work on this, because the VTK packages in Debian were
broken for a while, but today I gave it a try.
I should mention that I am not a VTK expert and so far packaging Caret
was simply joy -- even watching it compile with -Wall is beautiful ;-)
-- so I never had to dig deep into the code.
The main problem is that Caret (in some places) seems to assume a 32-bit
int as pointer type, whereas VTK (not sure since when) uses 'vtkIdType',
which varies over architectures. I tried to patch Caret, and for most
problematic code pieces that seems to work, but others are more tricky
-- up to the point were I think that I cannot do that 'just for Debian',
because I really have no clue about the side-effects. As a result Caret
in Debian is severely broken and not usable -- sadly.
Example:
caret_brain_set/BrainModelSurface.cxx
-------------------------------------
@@ -1069,7 +1069,7 @@ BrainModelSurface::convertToVtkPolyData() const
for (int j = 0; j < numTiles; j++) {
int v[3];
topology->getTile(j, v[0], v[1], v[2]);
cells->InsertNextCell(3, v);
getTile() wants 'int', but insertNextCell() wants 'vtkIdType'. With
recent GCC compilers this cannot be compiled. Moreover, simply casting
to vtkIdType might yield unexpected side-effects, depending on the actual
datatype of vtkIdType on a particular platform.
Also changing getTile() might be an option. it has...
void TopologyFile::getTile(const int tileNumber, int& v1, int& v2, int& v3)
const
{
int32_t* tiles = dataArrays[0]->getDataPointerInt();
v1 = tiles[tileNumber * 3];
v2 = tiles[tileNumber * 3 + 1];
v3 = tiles[tileNumber * 3 + 2];
}
... but I am not sure if tiles really needs to be 32bit.
That is a short summary of the situation. The good news is that only a
minor part of Caret is affected. However, IMHO the necessary fix is
beyond the scope of packaging a software, but really about compatibility
with recent VTK versions, so I decided that the only reasonable choice
is to report here and now and wait for an updated release -- sticking to
VTK 5.0 is no choice for distribution packages, of course. Debian
switched to VTK 5.2 and will switch to 5.4 shortly, Ubuntu as being
based on it will follow.
Michael
--
GPG key: 1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050
_______________________________________________
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users
