#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