Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#38375 closed defect (fixed)

Ports depending on wxWidgets* or wxPython should be ported to wxWidgets-3.0 or provide variants

Reported by: cooljeanius (Eric Gallager) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: afb@…, bfulgham@…, bugcutt@…, neurodroid (Christoph Schmidt-Hieber), eborisch (Eric A. Borisch), howarth@…, jameskyle@…, jjstickel (Jonathan Stickel), jyrkiwahlstedt, klaus.zimmermann@…, macports@…, markd@…, michaelld (Michael Dickens), mojca (Mojca Miklavec), raimue (Rainer Müller), rudloff@…, ryandesign (Ryan Schmidt), tenomoto (Takeshi Enomoto), usami-k@…
Port: bittorrent codeblocks erlang esdl FileZilla fityk gnuplot gnuradio gnuradio grass grass hugin-app lisaem mkvtoolnix otrproxy p5-alien-wxwidgets p5-graphics-gnuplotif p5-wx pgAdmin3 plplot poedit py-dsv py-pyface py-robotframework-ride py-winpdb py-wxpython py-wxpython30 py26-pyphant py26-wxpython py27-wxpython-devel relax rt-volume-rendering sounddecompress spe stimfit usbprog wxLua wxMaxima wxWidgets wxWidgets-devel wxWidgets-python wxWidgets30 wxd wxgtk wxstedit xcmh

Description (last modified by mojca (Mojca Miklavec))

I'm hijacking this ticket to request review of modifications I did in browser:users/mojca/wxports by individual port maintainers. (While I did not change all the ports yet - in particular the dependencies of wxPython 2.8 need some testing to see whether they are compatible with 2.9, the majority is done, I'll reply below with the exact status report.)

Because all ports need to be updated simultaneously, any ports that won't receive any feedback by the maintainers will be considered as "maintainer timeout" and committed (or broken), so please make sure that your ports still work after these changes and feel free to suggest improvements/modifications, in particular regarding option names. Please also check that I properly increased the version and/or revision.

Feel free to commit to my branch directly.

wxWidgets dependencies

port required (option name) maintainer(s)
wxWidgets 2.9:
aqua/pgAdmin3 YES jwa
devel/poedit YES raimue openmaintainer
gis/grass NO wxwidgets nomaintainer
math/gnuplot NO wxwidgets mojca openmaintainer
-> perl/p5-graphics-gnuplotif nomaintainer
math/wxMaxima YES usami-k openmaintainer
multimedia/mkvtoolnix NO wxwidgets nomaintainer
perl/p5-alien-wxwidgets YES nomaintainer
-> perl/p5-wx nomaintainer
science/gnuradio NO wxgui michaelld openmaintainer
science/plplot NO wxWidgets takeshi openmaintainer
portable to wxWidgets 2.9:
cross/usbprog YES macports lilalinux.net
graphics/hugin-app YES nomaintainer
lang/erlang NO wxwidgets bfulgham
-> graphics/esdl bfulgham
math/fityk YES nomaintainer
x11/xcmh YES aqua/x11 markd
conditionally portable to wxWidgets 2.9:
www/FileZilla YES rudloff strasweb.fr, openmaintainer
wxWidgets 2.8 only:
devel/wxd YES usami-k, openmaintainer
devel/codeblocks YES aqua/x11 afb
devel/wxstedit YES aqua/x11 afb
-> graphics/wxLua afb
emulators/lisaem YES ryandesign
graphics/rt-volume-rendering YES bugcutt gmail.com
security/otrproxy YES nomaintainer

wxPython dependencies

port dependency maintainer(s)
wxPython 2.8:
editors/spe py26-wxpython nomaintainer
net/bittorrent py25-wxpython nomaintainer
python/py-dsv py2*-wxpython nomaintainer
python/py-pyface (optional) py2*-wxpython jjstickel gmail.com, openmaintainer
python/py26-pyphant py26-wxpython klaus.zimmermann fmf.uni-freiburg.de, rowue
wxPython 2.9:
gis/grass py27-wxpython30 nomaintainer
python/py-winpdb py2*-wxpython-devel eborisch, openmaintainer
python/py-robotframework-ride py2*-wxpython(30) jwa
science/gnuradio py2*-wxpython-devel michaelld, openmaintainer
science/relax py27-wxpython-devel howarth bromo.med.uc.edu
science/stimfit py27-wxpython30 christsc gmx.de
commented out/disabled:
games/sounddecompress py26-wxpython ryandesign

Change History (20)

comment:1 Changed 8 years ago by ryandesign (Ryan Schmidt)

The wxWidgets situation in MacPorts is basically a disaster, which is mostly the fault of the developers of wxWidgets for not releasing a 64-bit compatible version, 3.0, which they've needed to do since the release of Snow Leopard 3.5 years ago already, and partly the fault of MacPorts maintainers for introducing so many different wxWidgets ports with conflicting naming styles and unclear differentiation between them.

I've suggested before, and continue to recommend, in as far as I understand wxWidgets at all, that the existing wxWidgets ports be deprecated in favor of new versioned ports, e.g. wxWidgets28 and wxWidgets30. This hasn't really been accomplished yet. See also #37819.

I would not hold up poedit as an example of how to handle the wxWidgets dependency correctly; on the contrary I find its method convoluted and bizarre.

comment:2 Changed 8 years ago by afb@…

It has always been MacPorts problem that it chose to name wxMac as "wxWidgets", but still also provide "wxgtk"...

As for Code::Blocks it requires wxMac, so the only way to build 64-bit is to use wxGTK or to contribute upstream.

comment:3 in reply to:  1 ; Changed 8 years ago by cooljeanius (Eric Gallager)

Replying to ryandesign@…:

I would not hold up poedit as an example of how to handle the wxWidgets dependency correctly; on the contrary I find its method convoluted and bizarre.

Sure, its method might be convoluted and bizarre, but sometimes that's what's necessary to provide desired functionality (in this case, compatibility with multiple versions of wxWidgets).

comment:4 in reply to:  3 Changed 8 years ago by larryv (Lawrence Velázquez)

Replying to egall@…:

Sure, its method might be convoluted and bizarre, but sometimes that's what's necessary to provide desired functionality (in this case, compatibility with multiple versions of wxWidgets).

The wxWidgets situation should probably be sorted out first.

comment:5 Changed 8 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:6 Changed 7 years ago by cooljeanius (Eric Gallager)

r105726 added wxWidgets30 compatibility to gnuplot (I'd count that as a step towards working towards fixing this ticket)

comment:7 in reply to:  6 Changed 7 years ago by cooljeanius (Eric Gallager)

Replying to egall@…:

r105726 added wxWidgets30 compatibility to gnuplot (I'd count that as a step towards working towards fixing this ticket)

Same with r105900 which closed #37344

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

Here are some of my thoughts:

  1. The majority of this mess is there just because wxWidgets 2.8 and 2.9 are not allowed to coexist. Many ports like gnuplot could simply default to 2.9, but they cannot because the port cannot demand using by default a package (wxWidgets 2.9) that conflicts with dependencies of another package, say codeblocks (which depends on 2.8). If versions 2.8 and 2.9 could coexist, life would be *a lot* easier. See my ticket #39807. My belief is that once a clear separation is done and conflict is removed, it will become a lot easier for port maintainers to add proper variants (and to implement variants properly). Let's solve that issue first.
  1. I believe that we need a way to quickly find all ports that depend on any wxWidgets version. This is particularly important when doing major changes on wxWidgets naming scheme, when introducing and testing new versions of wxWidgets (for example when version 3.0 will be out), when doing revbumps, ... What do you think of adding PortGroup wxWidgets 1.0 to every such port, even if the group doesn't do anything useful yet?
  1. We need consistent naming scheme for wx variants and consistent behaviour across the ports, taking into account that:
    1. There are ports that require wxWidgets and there are ports where wxWidgets are simply optional (gnuplot).
    2. There are ports that only work with one version, but not the other (only 2.8, only 2.9) and those that work with both. Also some that work with wxgtk (on freebsd).
    3. In most cases it probably isn't relevant which wxWidgets the port depends on, but in some cases it might be desirable to support both, at least for testing purposes.
    4. While we could probably focus on 2.9/3.0 now and only depend on 2.8 for ports that don't work with 2.9, we need to be prepared for the arrival of 3.2 with the naming scheme & naming strategy. Maybe even for 3.0-devel and alike ;)
    5. Version 2.8 doesn't work on 10.8(?) and doesn't allow building 64-bit binaries. Version 2.9/3.0 requires at least 10.5 (but probably 10.4 is not really supported any more?).
    6. Some ports already do some more or less advanced magic to use the "right" version of wxWidgets and special care is needed to "translate" those options properly.
  1. We need to write some guidelines for maintainers of ports which depend on wxWidgets. This is not a priority, but I believe that it needs to be done at some point.
  1. The path-style dependencies shouldn't be used because wxWidgets 2.8 and 2.9 are incompatible with each other (path-style can be used with released and development version that are closely related).
  1. In my opinion this transition needs to happen before the official 3.0 release, to leave enough time for bugfixing and reporting bugs upstream.
  1. I wouldn't force changing ports until (1) is done and (3) is clear/well-defined.

I don't know if the following is a good idea, but something non-intrusive like the following could be put into each port that depends on wxWidgets just to mark where the work needs to be done:

PortGroup wxWidgets 1.0

# which versions of wxWidgets are supported
# add comments whether it's known (not) to work or just hasn't been implemented/tested yet
wxwidgets.version  28 30
# or wxwidgets.compatibility

# for ports like gnuplot
wxwidgets.optional  yes

comment:9 in reply to:  8 Changed 7 years ago by cooljeanius (Eric Gallager)

Replying to mojca@…:

  1. The majority of this mess is there just because wxWidgets 2.8 and 2.9 are not allowed to coexist. Many ports like gnuplot could simply default to 2.9, but they cannot because the port cannot demand using by default a package (wxWidgets 2.9) that conflicts with dependencies of another package, say codeblocks (which depends on 2.8). If versions 2.8 and 2.9 could coexist, life would be *a lot* easier. See my ticket #39807. My belief is that once a clear separation is done and conflict is removed, it will become a lot easier for port maintainers to add proper variants (and to implement variants properly). Let's solve that issue first.

Agreed, making them not conflict would be a good idea.

  1. I believe that we need a way to quickly find all ports that depend on any wxWidgets version. This is particularly important when doing major changes on wxWidgets naming scheme, when introducing and testing new versions of wxWidgets (for example when version 3.0 will be out), when doing revbumps, ... What do you think of adding PortGroup wxWidgets 1.0 to every such port, even if the group doesn't do anything useful yet?

The group would have to actually exist first though, wouldn't it? Regardless of whether it actually does anything useful yet?

  1. We need consistent naming scheme for wx variants and consistent behaviour across the ports, taking into account that:
    1. There are ports that require wxWidgets and there are ports where wxWidgets are simply optional (gnuplot).
    2. There are ports that only work with one version, but not the other (only 2.8, only 2.9) and those that work with both. Also some that work with wxgtk (on freebsd).
    3. In most cases it probably isn't relevant which wxWidgets the port depends on, but in some cases it might be desirable to support both, at least for testing purposes.
    4. While we could probably focus on 2.9/3.0 now and only depend on 2.8 for ports that don't work with 2.9, we need to be prepared for the arrival of 3.2 with the naming scheme & naming strategy. Maybe even for 3.0-devel and alike ;)
    5. Version 2.8 doesn't work on 10.8(?) and doesn't allow building 64-bit binaries. Version 2.9/3.0 requires at least 10.5 (but probably 10.4 is not really supported any more?).
    6. Some ports already do some more or less advanced magic to use the "right" version of wxWidgets and special care is needed to "translate" those options properly.

Gah, that's confusing...

  1. We need to write some guidelines for maintainers of ports which depend on wxWidgets. This is not a priority, but I believe that it needs to be done at some point.

Implementing the naming scheme mentioned above would require some sort of guidelines to make sure that people follow the naming scheme.

  1. The path-style dependencies shouldn't be used because wxWidgets 2.8 and 2.9 are incompatible with each other (path-style can be used with released and development version that are closely related).

OK, I was just throwing ideas out there...

  1. In my opinion this transition needs to happen before the official 3.0 release, to leave enough time for bugfixing and reporting bugs upstream.

When is that supposed to be done?

  1. I wouldn't force changing ports until (1) is done and (3) is clear/well-defined.

What do you mean by "force" here?

I don't know if the following is a good idea, but something non-intrusive like the following could be put into each port that depends on wxWidgets just to mark where the work needs to be done:

PortGroup wxWidgets 1.0

# which versions of wxWidgets are supported
# add comments whether it's known (not) to work or just hasn't been implemented/tested yet
wxwidgets.version  28 30
# or wxwidgets.compatibility

# for ports like gnuplot
wxwidgets.optional  yes

Go for it. Actually write the PortGroup first though.

comment:10 in reply to:  8 Changed 7 years ago by ryandesign (Ryan Schmidt)

Replying to mojca@…:

  1. The majority of this mess is there just because wxWidgets 2.8 and 2.9 are not allowed to coexist.

Correct. This should be fixed.

  1. I believe that we need a way to quickly find all ports that depend on any wxWidgets version. This is particularly important when doing major changes on wxWidgets naming scheme, when introducing and testing new versions of wxWidgets (for example when version 3.0 will be out), when doing revbumps, ... What do you think of adding PortGroup wxWidgets 1.0 to every such port, even if the group doesn't do anything useful yet?

Why? You can use grep to identify those ports already.

  1. We need consistent naming scheme for wx variants and consistent behaviour across the ports, taking into account that:
    1. There are ports that require wxWidgets and there are ports where wxWidgets are simply optional (gnuplot).
    2. There are ports that only work with one version, but not the other (only 2.8, only 2.9) and those that work with both. Also some that work with wxgtk (on freebsd).
    3. In most cases it probably isn't relevant which wxWidgets the port depends on, but in some cases it might be desirable to support both, at least for testing purposes.
    4. While we could probably focus on 2.9/3.0 now and only depend on 2.8 for ports that don't work with 2.9, we need to be prepared for the arrival of 3.2 with the naming scheme & naming strategy. Maybe even for 3.0-devel and alike ;)
    5. Version 2.8 doesn't work on 10.8(?) and doesn't allow building 64-bit binaries. Version 2.9/3.0 requires at least 10.5 (but probably 10.4 is not really supported any more?).
    6. Some ports already do some more or less advanced magic to use the "right" version of wxWidgets and special care is needed to "translate" those options properly.

I've gone through all this before on the list. My opinion is that there should be wxWidgets28, wxWidgets30, wxWidgets32 ports. There should be no -devel ports. The ports should not conflict with one another. There should be no wx* variants; ports that need wx should depend on the latest supported stable version and be done with it. Maintainers who wish to test whether newer versions would work can edit their portfile locally. Currently, ports should depend on wxWidgets30 if compatible, even though it is not yet stable, because as you said 2.8 doesn't work with current OS X.

As for Tiger, it's unfortunate that the wx developers have dropped 10.4 support, but that's their choice to make. 10.4 support in MacPorts is dwindling. Maintainers may support it if desired, but don't have to. I wouldn't have a problem with wx ports not supporting Tiger anymore.

  1. The path-style dependencies shouldn't be used because wxWidgets 2.8 and 2.9 are incompatible with each other

And unnecessary because once (1) is fixed there will be only a single wx port providing any given file.

(path-style can be used with released and development version that are closely related).

Should not occur.

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

I just checked FileZilla and otrproxy. Neither of them compiles with wxWidgets 2.9.

With FileZilla it's relatively explicit. 4 years ago a ticket (http://trac.filezilla-project.org/ticket/4973) has been closed with wontfix and the following comment:

FileZilla requires wxWidgets 2.8

Note that wxWidgets 2.9 is an unstable development version, it shouldn't be used in a production environment.

even though they have a wx3 branch (http://svn.filezilla-project.org/filezilla/FileZilla3/branches/), but they haven't touched it for three years and I didn't try to compile that one yet.

Someone submitted a bunch of patches in October 2012 (http://trac.filezilla-project.org/ticket/8272). I'm not sure against which version exactly, but it's somewhere close to version 3.5.3 and I managed to apply the patches. They needed additional fixing (the patches have been tested on Windows & Linux, but some additional Mac code needed changes) and still didn't compile. They do nightly builds on a Leopard PowerPC machine.

Anyway: FileZilla requires some effort that goes beyond the scope of MacPorts. Someone really needs to collaborate with the upstream developers to get it working, otherwise it would be a lot of effort for very little benefit.

The port otrproxy isn't explicit about supporting 2.8 only, but I couldn't make it work in a few quick attempts either.

comment:12 in reply to:  11 Changed 7 years ago by cooljeanius (Eric Gallager)

Replying to mojca@…:

I just checked FileZilla... [it doesn't compile] with wxWidgets 2.9.

With FileZilla it's relatively explicit. 4 years ago a ticket (http://trac.filezilla-project.org/ticket/4973) has been closed with wontfix and the following comment:

FileZilla requires wxWidgets 2.8

Note that wxWidgets 2.9 is an unstable development version, it shouldn't be used in a production environment.

even though they have a wx3 branch (http://svn.filezilla-project.org/filezilla/FileZilla3/branches/), but they haven't touched it for three years and I didn't try to compile that one yet.

Someone submitted a bunch of patches in October 2012 (http://trac.filezilla-project.org/ticket/8272). I'm not sure against which version exactly, but it's somewhere close to version 3.5.3 and I managed to apply the patches. They needed additional fixing (the patches have been tested on Windows & Linux, but some additional Mac code needed changes) and still didn't compile. They do nightly builds on a Leopard PowerPC machine.

Anyway: FileZilla requires some effort that goes beyond the scope of MacPorts. Someone really needs to collaborate with the upstream developers to get it working, otherwise it would be a lot of effort for very little benefit.

I'd been working on a local copy of the FileZilla portfile, but I haven't gotten it working yet: https://github.com/cooljeanius/LocalPorts/blob/master/www/FileZilla/Portfile

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

Cc: bfulgham@… christsc@… eborisch@… howarth@… jjstickel@… klaus.zimmermann@… markd@… michaelld@… takeshi@… added; hvdwolf@… p.schmiedeskamp@… removed
Description: modified (diff)
Port: bittorrent erlang esdl gnuplot gnuradio gnuradio grass grass mkvtoolnix p5-alien-wxwidgets p5-graphics-gnuplotif p5-wx pgAdmin3 plplot poedit py-dsv py-mayavi py-pyface py-robotframework-ride py-winpdb py-wxpython30 py26-pyphant py26-wxpython py27-wxpython-devel relax sounddecompress spe stimfit wxLua wxMaxima wxWidgets wxWidgets-devel wxWidgets-python wxWidgets30 wxgtk wxstedit xcmh added
Summary: Ports depending on wxWidgets* should either use path-style dependencies or variants insteadPorts depending on wxWidgets* or wxPython should be ported to wxWidgets-3.0 or provide variants
Version: 2.1.3

comment:14 Changed 7 years ago by jjstickel (Jonathan Stickel)

Can I post a post a patch to py-pyface here, or should I open a separate ticket? I will just remove the wx variant from py-pyface for now.

py-mayavi has a potential dependency on wxpython through py-pyface, and so it need not be listed on its own.

comment:15 in reply to:  14 ; Changed 7 years ago by mf2k (Frank Schima)

Replying to jjstickel@…:

Can I post a post a patch to py-pyface here, or should I open a separate ticket? I will just remove the wx variant from py-pyface for now.

Please open a new ticket and attach the patch there and reference the ticket here. We don't want lots of patches attached to this ticket.

comment:16 in reply to:  15 Changed 7 years ago by jjstickel (Jonathan Stickel)

Replying to macsforever2000@…:

Replying to jjstickel@…:

Can I post a post a patch to py-pyface here, or should I open a separate ticket? I will just remove the wx variant from py-pyface for now.

Please open a new ticket and attach the patch there and reference the ticket here. We don't want lots of patches attached to this ticket.

OK. See ticket #40207.

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

Description: modified (diff)
Port: py-mayavi removed

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

Going through wxPython 2.8 dependencies (other than py-pyface):

  • bittorrent - completely outdated and abandoned
  • spe - latest release or commit in 2008, name explicitly mentions wxWidgets 2.6, so I wouldn't be too optimistic about it being functional with 2.9
  • py-dsv - released in 2003 (there was one more release in 2010 with a single download which is not included in MacPorts [yet])
  • py26-pyphant - requires some work (website has moved if nothing else)
  • grass - a bit broken

I wonder if anyone uses the first three ports at all and it seems like I don't even want to check anything other than modifying the dependency.

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

Resolution: fixed
Status: newclosed

I'm closing this ticket (commits mostly between r110234 and r110281). I probably introduced some problems during transition, but I leave the individual ports to maintainers / feel free to open a new ticket if a particular port is now broken.

comment:20 in reply to:  19 Changed 7 years ago by cooljeanius (Eric Gallager)

Replying to mojca@…:

I'm closing this ticket (commits mostly between r110234 and r110281). I probably introduced some problems during transition, but I leave the individual ports to maintainers / feel free to open a new ticket if a particular port is now broken.

Thanks for all your work on this, Mojca!

Note: See TracTickets for help on using tickets.