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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to