Opened 11 years ago

Closed 11 years ago

#40333 closed defect (fixed)

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

Reported by: mojca (Mojca Miklavec) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: jyrkiwahlstedt, rowue@…, ryandesign (Ryan Carsten Schmidt), jjstickel (Jonathan Stickel), cooljeanius (Eric Gallager), petrrr
Port: py-wxpython-2.8 spe grass py-dsv py-pyface py-robotframework-ride py26-pyphant

Description (last modified by 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.

Change History (10)

comment:1 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:2 Changed 11 years ago by petrrr

Cc: Peter.Danecek@… added

Cc Me!

comment:3 Changed 11 years ago by mojca (Mojca Miklavec)

Description: modified (diff)

comment:4 Changed 11 years ago by mojca (Mojca Miklavec)

Description: modified (diff)
Port: py-robotframework-ride py26-pyphant added; bittorrent py-rotoframework-ride py26-pypthant removed

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

comment:5 Changed 11 years ago by 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
        }
    }
}

comment:6 Changed 11 years ago by mojca (Mojca Miklavec)

Description: modified (diff)

comment:7 Changed 11 years ago by mojca (Mojca Miklavec)

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

comment:8 Changed 11 years ago by 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.

comment:9 Changed 11 years ago by 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.

comment:10 Changed 11 years ago by mojca (Mojca Miklavec)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.