py-wxpython-2.8 dependencies: add proper variants for proper use of wxWidgets-2.8 vs. wxgtk-2.8

[mojca (Mojca Miklavec)]

All dependencies of py-wxpython-2.8 need variants to account for the difference between linking against py-wxpython-2.8 +carbon and py-wxpython-2.8 +gtk. These ports are:

• gis/grass (see also #36904; active development, but no attempts to make it compatible with 3.0 yet)
• python/py-robotframework-ride (see also #40297; it builds against 3.0, but has problems, upstream is slowly working on compatibility with 3.0)
• python/py26-pyphant (see also #40347; likely to become compatible with 3.0 soon)
• python/py-pyface (see also #40207; wx is not a strict requirement, developers might be willing to fix problems)

Outdated/abandoned ones (all ports are noarch, so no change is needed for successful compilation):

• editors/spe
• python/py-dsv (wx is optional)
• net/bittorrent (deleted)

Plus maybe those with (temporarily?) disabled support for wxWidgets:

• games/sounddecompress

On Xcode >= 4.4 py-wxpython-2.8 can only be installed with +gtk, so there is no problem, but with earlier releases of Xcode where +carbon is default, these dependencies need to be aware of incompatibility with x86_64, clang and possibly other minor issues.

On top of that some ports are conditionally compatible with py-wxpython-3.0 and one needs to keep in mind that py27-wxpython-2.8 is conflicting with py27-wxpython-3.0 and the reasonable compromise I see is to allow these ports to link against py26-wxpython-2.8 in order to allow side-by-side installation with dependencies of py27-wxpython-3.0.

I would suggest to provide options with consistent/equal names for all the listed ports, but I'm looking for suggestions.

Just an additional note is that at least bittorrent, py-dsv and spe seem relatively "abandoned" upstream and also have no maintainer.

[cooljeanius (Eric Gallager)]

Cc Me!

[petrrr]

Cc Me!

[mojca (Mojca Miklavec)]

Bittorrent removed from the list of affected ports after removing it from repository (r115270), fixed typos in other port names.

[mojca (Mojca Miklavec)]

Here are some thoughts.

I would suggest to use the same names for variants as for wxWidgets dependents, namely:

• variant wxwidgets30 conflicts wxgtk28 wxwidgets28 description {Use wxPython 3.0 (not fully functional yet)}
• variant wxwidgets28 conflicts wxgtk28 wxwidgets30 description {Use 32-bit Carbon-based wxPython 2.8}
• variant wxgtk28 conflicts wxwidgets28 wxwidgets30 description {Use GTK-based wxPython 2.8}

Some restrictions:

• wxwidgets30 option shouldn't be available for ${python.version} < 27

The variant wxwidgets28 could do something like the following:

# this also sets `supported_archs i386 ppc` which is nice,
# while on the other hand it probably shouldn't blacklist `clang`
wxWidgets.use           wxWidgets-2.8
depends_lib-append      port:py${python.version}-wxpython-2.8
require_active_variants port:py${python.version}-wxpython-2.8 carbon gtk

so maybe the syntax could be:

variant wxwidgets28 conflicts wxgtk28 wxwidgets30 description {Use 32-bit Carbon-based wxPython 2.8} {
    wxPython.depends    ${python.version} wxWidgets-2.8
    # conditionally print the following notes on x86_64
    notes "To run, use 'arch -i386 <binary_name>' to use 32-bit architecture"
}

where "wxPython.depends 27 wxWidgets2.8" could take care of the following:

universal_variant   no
supported_archs     i386 ppc

pre-fetch {
    # 10.8 (or later) -or- 10.7 with Xcode 4.4 (or later)
    if {${os.major} >= 12 || [vercmp $xcodeversion 4.4] >= 0} {
        ui_error "Port depends on wxWidgets-2.8 which cannot be built on Moc OS X >= 10.7 with Xcode >= 4.4"
        return -code return "Port depends on wxWidgets-2.8 which cannot be built on Moc OS X >= 10.7 with Xcode >= 4.4"
    }
}

depends_lib-append      port:py${python.version}-wxpython-2.8
require_active_variants port:py${python.version}-wxpython-2.8 carbon gtk

and the strategy to select the right variant could be something like the following (partially pseudocode):

if {![variant_isset wxwidgets30] && ![variant_isset wxwidgets28] && ![variant_isset wxgtk28]} {
    # if wxpython-2.8 is already installed, use the installed one
    if {wxPython.is_installed ${python.version} 2.8} {
        # if py2X-wxpython-2.8 +carbon was installed
        if { wxPython.is_active ${python.version} wxWidgets-2.8 } {
            default_variants +wxwidgets28
        } else {
            default_variants +wxgtk28
        }
    } else {
        if {wxPython.is_carbon_supported} {
            default_variants +wxwidgets28
        } else {
            default_variants +wxgtk28
        }
    }
}

[mojca (Mojca Miklavec)]

As mentioned on the mailing list, I'm thinking of simply dropping support for py-wxpython-2.8 +carbon.

[mojca (Mojca Miklavec)]

I made +gtk default variant of py-wxpython-2.8 in r116066 as a compromise to satisfy those who really want to keep using the Carbon-based wxPython (but leaving them on their own in case of problems related to 32-bit applications) and to keep simplicity in port depending on wxPython.

Then we can have just two variants for ports that conditionally support version 3.0:

• wxwidgets30 or wxpython30
• wxwidgets28 or wxpython28

The second one will simply depend on py-wxpython-2.8, no matter which variant gets installed. If the user asked for +carbon, the user needs to deal with incompatibilities and problems like the need to install and run a specific port as 32-bit.

Now:

• I believe that spe and py-dsv are pure Python packages, so no compilations are involved and they don't care what they are using. And they don't work with 3.0 anyway, so no options are needed.
• The grass port is broken and needs someone to fix it
• The ports for py26-pyphant are outdated and I wouldn't touch them until a new version gets released.
• py-robotframework-ride should finally work as-is on 10.6 (defaulting to 2.8) and build properly on the buildbot (but two variants could be added to allow the switch to 3.0 for testing)
• I'll add two variants to py-pyface.

[mojca (Mojca Miklavec)]

I'm waiting for maintainer to either accept or decline the patch for py-robotframework-ride, but it has a separate ticket open. The ports for grass and py-pyface were fixed, pyphant is semi-broken and not worth patching now, but will hopefully fully support wxWidgets 3.0 when it "raises from the dead". spe and py-dsv don't need anything.

Thus I'm closing the ticket.