InsightToolkit should use python26 variant

[jeremyhu (Jeremy Huddleston Sequoia)]

Use python25 and python26 as variant names like other ports.

[jeremyhu (Jeremy Huddleston Sequoia)]

and you should be able to solve your python 2.6 linking problem with something like this:

configure.ldflags-append -F${prefix}/Library/Frameworks

[jeremyhu (Jeremy Huddleston Sequoia)]

actually -F${frameworks_dir}

[jmroot (Joshua Root)]

Wouldn't what you link against change based on what the user has python_select-ed if you use -F${frameworks_dir}?

[jeremyhu (Jeremy Huddleston Sequoia)]

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.

[dweber@…]

With regard to naming convention on the variants or ports, there is obviously a long history of using "py" in port names, like port search py25*. In that light, the InsightToolkit @3.16 etc. has adopted the variant names of py24, py25, py26, etc.

I've thought about whether the wrapping should be an independent build from the main c++ build and install. According to some discussions on the ITK email list about wrapping, this may be possible, at least for python wrapping. So something like py25-InsightToolkit and py26-InsightToolkit may be possible. Of course, this would raise the possibility of things like py25-InsightToolkit314, py25-InsightToolkit316, and so on for py26 etc., to provide all the permutations of python and ITK versions available. However, it's not that likely that anyone would want so many choices and I don't have the time to work on all that in the near future.

If you get the py26 variant to work, it could become the default instead of py25. Please submit a Portfile that works, if you get it working.

BTW, this is not a defect. The port has clearly disabled py26 to avoid defects that were identified before releasing the port. I consider a defect anything that causes a failure of the port to install as intended. So I consider this ticke to be a request or an enhancement. Thanks for your consideration.

[dweber@…]

Replying to 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!

[jeremyhu (Jeremy Huddleston Sequoia)]

Yes, there are 'py26-*' ports, but it's common for ports to use 'python25' and 'python26' as the name of variants. The only exception to this is the 'vtk-devel' which is equally broken (and your port).

I've updated the ports: r63941

[jeremyhu (Jeremy Huddleston Sequoia)]

I'm not sure the best way to get python2.6 framework linking working right with cmake, but I'll make another ticket with that to not mix issues.

[dweber@…]

OK, looks like a consistent change that will not break anything.

Out of curiosity, I've noticed a change to set pyLib ... in the proc setPython section, i.e.:

    575 proc setPython { {major 2} {minor 6} } {
    576     global pyVer python pyPort pyBin pyLib pyInc pyFrame pySite
    577     set pyVer       ${major}.${minor}
    578     set python      python${pyVer}
    579     set pyPort      python${major}${minor}
    580     set pyFrame     Library/Frameworks/Python.framework/Versions/${pyVer}
    581     set pyLib       ${pyFrame}/Python
    582     #set pyLib       lib/${python}
    583     set pyBin       bin/${python}
    584     set pyInc       include/${python}
    585     set pySite      lib/${python}/site-packages
    586     if [string match "2.6" ${pyVer}] {
    587         # python2.6 is a true framework installation; whereas installs for 2.4
    588         # and 2.5 contain symlinks in the framework path to the prefix path; and
    589         # those symlinks can break the file_map stage of port activation.
    590         set pyBin   ${pyFrame}/bin/${python}
    591         set pyInc   ${pyFrame}/include/${python}
    592         set pySite  ${pyFrame}/lib/${python}/site-packages
    593     }
    594 }

I don't know how to track when or who made that change. Is there an svn command to track a change for a specific section of the file? (I don't know of any.)

If you run ls -l /opt/local/lib/python*, you get similar results for 2.3 - 2.5, and a different result for 2.6.

Again, there are differences from 2.4-2.5 vs. 2.6 when you run

$ ls -l /opt/local/Library/Frameworks/Python.framework/Versions/2.?/lib/
/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/:
total 4.0K
lrwxr-xr-x 1 root wheel 24 Oct  2 15:04 python2.4 -> /opt/local/lib/python2.4/

/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/:
total 4.0K
drwxr-xr-x 3 root admin 102 Oct 22 17:37 pkgconfig/
lrwxr-xr-x 1 root wheel  24 Feb 10 09:23 python2.5 -> /opt/local/lib/python2.5/

/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/:
total 28K
-rwxr-xr-x   2 root wheel  20K Jun 24  2009 libpyglib-2.0-python2.6.0.dylib*
lrwxr-xr-x   1 root admin   31 Jun 24  2009 libpyglib-2.0-python2.6.dylib -> libpyglib-2.0-python2.6.0.dylib*
-rwxr-xr-x   2 root wheel 1.3K Jun 24  2009 libpyglib-2.0-python2.6.la*
drwxr-xr-x   6 root admin  204 Feb  8 15:04 pkgconfig/
drwxr-xr-x   3 root wheel  102 Oct 16 16:59 pygtk/
drwxr-xr-x 631 root admin  21K Oct 27 15:42 python2.6/

This is why the setPython proc in the InsightToolkit port handles the paths differently for 2.6.

(Maybe this should go into the 'new' ticket.)

[dweber@…]

Replying to jeremyhu@…:

Yes, there are 'py26-*' ports, but it's common for ports to use 'python25' and 'python26' as the name of variants. The only exception to this is the 'vtk-devel' which is equally broken (and your port).

I've updated the ports: r63941

Assume we have ports installed with the +py25 variant.

Will this change break port upgrade InsightToolkit when the port reaches a new release version (like 3.18.0)?

[jeremyhu (Jeremy Huddleston Sequoia)]

@dwebber: Check out 'svn blame'

 51322 dweber@macports.org     set pyLib       ${pyFrame}/Python
 51478 dweber@macports.org     #set pyLib       lib/${python}

Looks like it was your fault ;)

[jeremyhu (Jeremy Huddleston Sequoia)]

well since python25 is the default variant, they'll go from py25 to python25.

The issue is if they are at +py24 and don't have python24 in their variant list... but I can't imagine anyone actually being in that use set.

[dweber@…]

Ah, yea, I'm the culprit, and no comment about why I did that! Damn.

As for upgrade issues, I often run sudo port upgrade -uR ${ports}. For example,

...
--->  Uninstalling xorg-dri2proto @2.2_0
Warning: Skipping upgrade since InsightToolkit 3.16.0_2 >= InsightToolkit 3.16.0_2, even though installed variants "+doc+examples+py25+shared+testing+wrap" do not match "+doc+examples+python25+shared+testing+wrap". Use 'upgrade --enforce-variants' to switch to the requested variants.
...

I might be grateful, in this case, that it didn't run the upgrade to save me all the build time. However, it makes a lot of sense to rebuild if the link library deps are upgrading.