wxWidgets vs. wxWidgets-devel: a proposal

[Kuba Ober]

Ok, I presume we can keep the port names and only issue wxWidgets28 when
30 becomes stable. So I won't be pushing for any wxWidgets port renaming.

There are two issues, then:

1. Some wxWidgets-using projects abandoned support for 2.8.

2. Even for projects that support both 2.8 and 2.9, like, say wxMaxima, the users
may want to compile it for 64 bits -- IMHO such support should be default. It's
a bit irksome when simply installing wxMaxima pulls in a bazillion universal ports.

So, here's what I propose:

1. For projects that abandoned support for 2.8, a separate package will track the
most recent version that supported 2.8. For fityk, we'd have fityk09 depending on
wxWidgets 2.8 (currently, or wxWidgets28 when that port materializes, that's
when wxWidgets releases 3.0).

2. For projects that support both 2.8 and 2.9, I'd suggest switching to wxWidgets
2.9 (called wxWidgets-devel at the moment), and adding wxWidgets28 as a variant.
Someone who runs into specific issues can then use 2.8 and be limited to 32 bit builds.
I don't think that 2.9 is, in practice, any less stable than 2.8.

One has to be careful with what "stable" means. wxWidgets-devel may not be "stable", but many projects
are not maintaining old branches that last supported wxWidgets 2.8, or are testing less on wxWidgets 2.8.

Cheers, Kuba

On Sep 25, 2012, at 9:11 AM, Andrea D'Amore wrote:

> 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