[MacPorts] #19000: vtk 5.4.0

[MacPorts]

#19000: vtk 5.4.0
---------------------------------+------------------------------------------
 Reporter:  dweber@…             |       Owner:  macports-tickets@…                   
     Type:  enhancement          |      Status:  new                                  
 Priority:  Normal               |   Milestone:  Port Enhancements                    
Component:  ports                |     Version:  1.7.0                                
 Keywords:  VTK vtk 5.4          |        Port:  vtk54 vtk5                           
---------------------------------+------------------------------------------

Comment(by dweber@…):

 I'm doing a review of all the settings used in vtk (4.x) and vtk5, with
 regard to variables for RPATH and INSTALL_DIR in cmake (also reviewing the
 cmake book to make sure I understand these variables).  There are some
 differences in these settings between the two ports, with vtk5 using a LOT
 more of these settings than vtk (4.4), and vtk5 sneaks in a DYLD
 environment setting into the build.env (I wonder if that is required to
 sort-of "undo" the BUILD_WITH_INSTALL_RPATH setting).  vtk5 uses
 INSTALL_RPATH_USE_LINK_PATH - will that point back to ${worksrcpath} or
 the destroot; what happens if they are removed?  The post-configure hack
 in vtk5 seems a curiousity to me - why isn't that handled by a cmake
 variable?  I'm not clear on how all these settings are working during the
 build and install into destroot (I assume cmake settings are independent
 of the activation phase); I need to test a fake destroot build or step
 through each of the macports phases for my peace of mind.

 In vtk5, it might be better to have some of the post-destroot stuff as
 variants for +doc +data +examples?  The data install path is generic
 rather than version specific, ie:
 -DVTK_DATA_ROOT:PATH=${prefix}/share/VTKData/.  vtk5 +python is using
 python25 - should we update to python26?  (I assume python30 is a bleeding
 edge.)

 I would prefer to see cocoa as the default variant, rather than x11.
 Perhaps I'm missing something about additional wrapping or something - why
 is x11 the default variant in vtk5?

 These comments should probably go into a specific ticket on vtk (4.4), but
 I'm feeling lazy...  According to the cmake book,
 CMAKE_BUILD_WITH_INSTALL_RPATH over-rides CMAKE_SKIP_RPATH, so these
 settings in vtk (4.4.2) may be redundant (they might be effectively
 consistent anyhow).  I'm not clear why it should BUILD_WITH_INSTALL_RPATH
 - shouldn't the RPATH get reset during the installation?  It might be wise
 to change CMAKE_INSTALL_NAME_DIR to a version specific path in vtk (4.4),
 how about ${prefix}/lib/vtk-4.4?  vtk (4.4) sets ${worksrcdir} - should
 that be ${worksrcpath}?  Should vtk (4.4) use ${x11prefix} instead of
 ${prefix} in the +x11 variant and should that be a default variant?  In
 vtk (4.4), all the -D config args are followed by a space, whereas vtk5
 omits the space (the latter seems to make it easier to config delete in
 variants - no quotes required around the "-D <var>:<type>=<val>").

 In the long_description, it would seem useful to include some comments
 about the variants.  Although variants can specify 'requires' and
 'conflicts' clauses, it might help users to know about those before
 selecting a variant.

 I'm content to leave vtk5 alone.  My focus is on my local repository
 version of vtk54 for testing a few things.  When I test and clarify my
 local repository version, I'll run an svn update on the trunk version of
 both vtk5 and vtk54 (to get all the latest work), double-check my local
 version with a diff against the trunk, and then try to consolidate into an
 svn commit for vtk54 (leaving vtk5 alone).  If that works and we have a
 consensus about vtkXY version naming, then (a) vtk54 might become vtk5
 (and we remove any ports for vtk5Y), or (b) vtk5 becomes vtk52 and vtk54
 remains (or vtk5 becomes vtk52 and vtk54 becomes vtk5).

 Please feel free to work on vtk54 as you please (it has openmaintainer!).

-- 
Ticket URL: <http://trac.macports.org/ticket/19000#comment:10>
MacPorts <http://www.macports.org/>
Ports system for Mac OS