[prev in list] [next in list] [prev in thread] [next in thread]
List: macports-dev
Subject: Case in point for wxWidgets split.
From: Kuba Ober <kuba () mareimbrium ! org>
Date: 2012-09-21 19:48:17
Message-ID: 0DBFC43C-5913-4958-B16B-4D8D6268B3ED () mareimbrium ! org
[Download RAW message or body]
I'll demonstrate with a specific case what I intend to do with wxWidgets.
fityk, a nice (because it's Polish, duh) curve fitting tool, supports wxWidgets 2.8 up to 0.9.8.
From 1.0.0 onwards, it needs wxWidgets >= 2.9.1.
Here's what I want to do, illustrated with this case:
1. wxWidgets28 is the renamed current wxWidgets port, and tracks 2.8 wxWidgets releases.
Note that this port won't have "replaces wxWidgets" in it!
2. wxWidgets is the renamed current wxWidgets-devel port, and tracks 2.9 releases
This port will be marked "replaces wxWidgets-devel". wxWidgets-devel will come back for 2.10
or 3.0, and then the wxWidgets port will have to stop replacing wxWidgets-devel, of course.
3. fityk is renamed to fityk0 and made dependent on wxWidgets28; no functionality is changed
4. fityk0 is upgraded to 0.9.8 (latest version that supported wxWidgets 2.8)
5. fityk is a new port that tracks current fityk releases and depends on wxWidgets
Existing users will see a seamless upgrade to the most recent wxWidgets and most recent fityk.
*NEW* Users on Tiger need to manually install compatible fityk0, and that will automatically
pull in wxWidgets28. This is IMHO a minor inconvenience.
A single commit will have to implement #1 and #3, so that nothing gets broken by partial updates,
even though I will of course submit it in separate patches.
There's 17 ports that depend on current 2.8 wxWidgets, and 3 ports that depend on wxWidgets-devel.
So #1 will be one patch and #3 will be 17 patches, all of them to relevant Portfiles, and will have
to be applied in a single commit.
For the 3 ports that depend on wxWidgets-devel, there will be one new Portfile and 3 patches to
existing portfiles -- again, to be applied in a single commit.
I'd like a go ahead before I start working on this. Please comment on this plan! It's important
to move ahead, IMHO, to stop having dirty per-port hacks that detect xcode versions and other jazz
like that. That's what was recently planned for pgAdmin3 and would have been a mess, since pgAdmin3
is not the only port in such a predicament!
Cheers, Kuba
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic