wxWidgets vs. wxWidgets-devel: a proposal

[Andrea D'Amore]

On Fri, Sep 21, 2012 at 3:50 PM, Kuba Ober <kuba at mareimbrium.org> wrote:
> I'm trying to get wxWidgets and packages that use it running on 64 bit cocoa systems. Obviously
> the way forward is to get everything on wxWidgets 2.9, but for some packages it may not be
> possible just yet. Here's what I propose:

> - rename wxWidgets to wxWidgets28, adjust all dependent packages appropriately
> - rename wxWidgets-devel to wxWidgets (that's 2.9.x)
> - use wxWidgets 2.9 with all packages where upstream claims to support it, on all architectures

wxWidgets stable is 2.8 and 2.9 is development branch so the actual
port naming is just fine. When wxWidgets will hit 3.0 then port
wxWidgets will be updated and (eventually) wxWidgets28 will be
created.

It's an incidental issue that 2.8 cannot build x86_64 due to its usage
of Carbon, but consider that this problem will fade out and can be
handled in Portfile like wxMaxima does in r98113, cf. [1,2].

We have 17 ports depending on wxWidgets:
  2 of them (gnuplot, wxMaxima) already offer a wxwidgets-devel variant;
  1 is the wxwidgets26 py-wxwidgets port that has already been pointed
out in this thread;
  2 py-wxwidgets should probably be merged using subports and counts as one;

This leaves with 13 ports to deal with.

I'd rather define a conventional rule for port maintainers to provide
a "wxwidgets-devel" variants (maybe a portgroup?) than break the
naming rule and play around with replaced_by.



[1] http://trac.macports.org/changeset/98113
[2] http://trac.macports.org/ticket/36157

-- 
Andrea