UPDATE: VTK-4.4.2

[cssdev@…]

VTK 4.2 follows one version of the VTK API, but VTK 4.4 provides a transition API moving toward VTK 5. There are "interim" releases available from the VTK website:

• ​http://www.vtk.org/get-software.php#interim
• ​http://public.kitware.com/pipermail/vtkusers/2003-December/070809.html

It would be useful to have a way to grab this interim release for use with code that targets the newer API. The CVS HEAD does include development for 4.4.x, but the interim releases might be a little more stable than checking out the latest bleeding edge code from CVS. Technically, the devel variant should be version 4.4, not 4.3. Since VTK 4.2 and VTK 4.4 are considered different, how might DarwinPorts support both these versions?

[cssdev@…]

I checked out the latest version from cvs (-D 2005/07/07), and it works fine with the resolution to BUG #3895 put into place. I can provide VTK-20050707.tar.bz2 for use in compiling the latest development version of VTK 4.5. What might be the best way to differentiate between the different versions? Should I name the new port 'vtk-interim' or 'vtk5', for example?

[olegb@…]

any update on this Chris?

maybe name the port vtk4 vtk5 or somethin' ?

[cssdev@…]

I'm working on a separate vtk5 port now that VTK 5.0.0 has been released by Kitware.

[css@…]

Reassigning bug to port maintainer.

[css@…]

I'll create a separate vtk44 port in addition to a newer vtk5 port.

[css@…]

VTK 4.4.2 is listed by Kitware as the previous release. so this port should change from something new to an update.

[css@…]

update to vtk 4.4 with adjusted patches

[css@…]

patches for build vtk 4.4 with gcc4

[css@…]

I hope this worked ... I didn't finish testing before it was committed.

[css@…]

Changes are still uncommitted for VTK 4.4, and I'm reopening the ticket because it's a completely different version from the newer vtk5.

[css@…]

Picking this back up ... I'll apply the patches for gcc4 if ${os.major} >= 8, and that should fix several things. I'll need to look more closely at the X11 handling, because I need to make sure that it looks in ${x11prefix} and can properly utilize MacPorts libs in addition to the regular Mac OS X X11 libs.

[css@…]

updated Portfile for Leopard and x11prefix

[css@…]

Replying to css@…:

I'll need to look more closely at the X11 handling

I'm concerned about messages like:

CMake Warning at Rendering/Testing/Cxx/CMakeLists.txt:29 (ADD_EXECUTABLE):
  Cannot generate a safe linker search path for target TimeRenderer because
  there is a cycle in the constraint graph:

    dir 0 is [.]
    dir 1 is [/opt/local/var/macports/build/_Users_Shared_macports_dports_graphics_vtk/work/VTK/bin]
    dir 2 is [/usr/X11R6/lib]
      dir 3 must precede it due to link library [libSM.dylib]
    dir 3 is [/opt/local/lib]
      dir 2 must precede it due to link library [libGLU.dylib]

  Some of these libraries may not be found correctly.

I'll start a build this morning, and I'll take a look at the results later.

[css@…]

Committed to r47882!

[anonymous]

Milestone Port Updates deleted