wxWidgets vs. wxWidgets-devel: a proposal

Kuba Ober kuba at mareimbrium.org
Fri Sep 21 06:50:54 PDT 2012


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

1. Are there any specific problems with wxWidgets 2.9 on older systems (what older systems)?
2. Do we even need to care about anything prior to Leopard?

My initial goal is to get wxMaxima and pgAdmin3 to simply use wxWidgets 2.9. That is, I presume,
how it's all meant to work anyway, so if there are bugs they can be fed to upstream etc.

If there is a reason for a particular package to be frozen in an older version and use older
wxWidgets, then I presume it should go to a separate package.

Case in point: If there's a need to stick with wxWidgets28 to get pgAdmin3 working on older systems,
and if only older pgAdmin3 1.14 will work that way, then we should simply have pgAdmin3_114 that
depends on wxWidgets28.

Please let me know if it makes sense.

I think that the idea to switch wxWidgets version dependency in a package that uses it basing
on the version of the OS is workable, but basing it on version of Xcode makes no sense to me. What
would be the rationale for that?

Also, generally I presume for a dependent package, there are three ranges of versions: "old"
range that only supports 2.8, potentially empty "overlap" range that supports both 2.8 and 2.9,
and "current" range that supports 2.9. The "overlap" range is the only one where switching
wxWidgets dependency based on platform version makes any sense.

Cheers, Kuba


More information about the macports-dev mailing list