[MacPorts] #19569: vtk-devel doesn't build/install python26 libs (python26 framework build)

[MacPorts]

#19569: vtk-devel doesn't build/install python26 libs (python26 framework build)
----------------------------------+-----------------------------------------
  Reporter:  santagada@…          |       Owner:  dweber@…                               
      Type:  defect               |      Status:  closed                                 
  Priority:  Normal               |   Milestone:                                         
 Component:  ports                |     Version:  1.7.1                                  
Resolution:  worksforme           |    Keywords:  vtk vtk-devel framework python26 python
      Port:  vtk-devel            |  
----------------------------------+-----------------------------------------
Changes (by dweber@…):

  * status:  new => closed
  * resolution:  => worksforme


Comment:

 From the install synatax you have reported in this ticket, it looks like
 you have the initial update to vtk-devel (at 5.4.0), which is still a work
 in progress.  That is, don't expect everything to work with *-devel port.

 The main problem with the prior port revision (0) was with:
 -DVTK_PYTHON_SETUP_ARGS
 Although the wrapping was fine, the install failed.  This variable setting
 was not getting through to cmake properly.  It took forever to debug that
 nasty little critter!  In addition, the python26 variant has the wrong
 header and site paths.  Your library setting in the ticket should work for
 the build, but the problem is the python setup args was faulty.  Those
 variables are all now:

 {{{
     configure.args-append \
         -DVTK_WRAP_PYTHON:BOOL=ON \
         -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
 -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/Library/Frameworks/Python.framework/Headers
 \
         -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
         -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
         -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/${python} \
         -DVTK_PYTHON_SETUP_ARGS:STRING='--prefix=${pyframe}
 --root=${destroot}'
 }}}

 On my system, this is all working now in the latest revision (actually, my
 current testing port will have to use a more version specific library path
 for the framework, as you point out in the ticket).  I've commited a
 revision to the svn trunk for vtk-devel (revision 1) last Friday.  Check
 if that revision is in the release ports; use {{{port selfupdate}}}, then
 {{{port info vtk-devel}}} should say:

 {{{
 vtk-devel @5.4.0, Revision 1 (graphics, math, science, devel)
 Variants:    boost, carbon, cocoa, darwin_9, data, doc, examples, java,
 mpi, mysql, odbc, pgsql, py25, py26, shared, tcl,
              tcl_apple, testing, universal, x11

 An open source, freely available software system for computer graphics,
 image processing, and visualization used by thousands of
 researchers and developers around the world. VTK consists of a C++ class
 library, and several interpreted interface layers
 including Tcl/Tk, Java, and Python.
 Homepage:    http://www.vtk.org/

 Build Dependencies:   cmake, readline
 Platforms:            darwin
 Maintainers:          dweber at macports.org openmaintainer at macports.org
 }}}

 If not, you might try to get it from the svn trunk at:

 http://trac.macports.org/browser/trunk/dports/graphics/vtk-devel/Portfile

 I did a lot of work on python, tcl, java wrapping installs for vtk-devel
 last week, to check the install paths and the dylib rpaths.  I checked the
 python installs for both py25 and py26 variants.  The new revision uses
 the names py25 and py26 for those variants (not python26).  As this is a
 work in progress, I've taken the liberty to rename or otherwise change
 variants at will.

 I'm now working on the database backends (mysql, pgsql, odbc variants).
 The goal is to have the vtk-devel install tested within a few weeks.  The
 functionality is another thing.  Once we know the install and the
 functionality are stable, vtk-devel should be become vtk (and possibly
 vtk5 too).

 There are more variants, including options to use boost and mpi.  I will
 not have time and patience to test all of the variant combinations (unless
 there is an automatic system in macports dev for generating and testing
 all the possible variant combinations for a port).

 Best, Darren

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