[MacPorts] #23762: InsightToolkit should use python26 variant

MacPorts noreply at macports.org
Thu Feb 18 12:08:48 PST 2010


#23762: InsightToolkit should use python26 variant
-----------------------------------+----------------------------------------
 Reporter:  jeremyhu@…             |       Owner:  dweber@…           
     Type:  request                |      Status:  new                
 Priority:  Normal                 |   Milestone:                     
Component:  ports                  |     Version:  1.8.2              
 Keywords:                         |        Port:  InsightToolkit     
-----------------------------------+----------------------------------------

Comment(by dweber@…):

 Replying to [comment:4 jeremyhu@…]:
 > Yes, it should always have -F${frameworks_dir} ... the problem is that
 the build system ignores configure.ldflags:
 >
 > :info:build /usr/bin/c++   -mmacosx-version-min=10.6 -fpermissive
 -ftemplate-depth-50 -Wall -Wno-deprecated -no-cpp-precomp   -ftemplate-
 depth-50 -Wall -Wno-deprecated -no-cpp-precomp -O2 -g -dynamiclib
 -headerpad_max_install_names -Wl,-flat_namespace,-U,_environ
 -Wl,-flat_namespace,-U,_environ    -o
 ../../../bin/libSwigRuntimePython.dylib -install_name
 /opt/local/var/macports/build/_Users_jeremy_src_macports-
 trunk_dports_graphics_InsightToolkit/work/InsightToolkit-3.16-build/bin/libSwigRuntimePython.dylib
 CMakeFiles/SwigRuntimePython.dir/swigrunPython.o -L.
 -L/opt/local/var/macports/build/_Users_jeremy_src_macports-
 trunk_dports_graphics_InsightToolkit/work/InsightToolkit-3.16-build/bin
 -framework Python
 >
 > So the fix would be in fixing the build system to respect the
 environment variables we give it.


 If so, then we might file a ticket on cmake and not InsightToolkit?
 Actually, it may be a ticket at the level of cmake with kitware
 (upstream).

 I'm a little foggy on the details of why it does work for py25 and does
 not work for py26.  At the time of creating these variants, there were
 variations in the installation path configurations for py25 and py26.  You
 can see an attempt to adjust for this in the procedure called
 {{{setPython}}} in this port (about line 575).

 Anyhow, here are the comments in the Portfile that were made at the time
 of testing this variant:

 {{{
     656 # Regardless of the pyLib setting for py26, cmake or the wrap
 config sets
     657 # the string "-framework Python", but this "-framework Python"
 setting actually
     658 # gets resolved by the link process into the Apple system
 /Framework path rather
     659 # than macports!  I'm not clear about how to control this, so the
 py26 variant
     660 # must be disabled for now.  If it's enabled, add the py26 variant
 to the
     661 # conflicts of py24 and py25.
 }}}

 Help to resolve this mystery is greatly appreciated!

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


More information about the macports-tickets mailing list