On Fri, Sep 21, 2012 at 3:50 PM, Kuba Ober <k...@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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
