1 |
On Tue, 2006-12-12 at 15:46 +0100, Florian Kamm wrote: |
2 |
> Hello, |
3 |
|
4 |
Hey, |
5 |
|
6 |
> I am currently developing applications using the great wxWidgets GUI |
7 |
> framework and I noticed that the appropriate gentoo packages are not |
8 |
> very actively maintained. |
9 |
|
10 |
Yeah, I've been concentrating on GNOME-2.16 more (other than being lazy |
11 |
and slacking in general), but that's handled now and I can move |
12 |
concentration to wxWidgets for a while again. |
13 |
|
14 |
> So I think about contributing either to the |
15 |
> maintenance of already existing packages (including the wxWidgets |
16 |
> library itself) or to the development of new ebuilds concerning projects |
17 |
> which use the wxWidgets library. |
18 |
> E.g. some work could be done to support different slots of the wxWidgets |
19 |
> library (coexisting release and debug versions and/or coexisting major |
20 |
> releases). This might yield to the development of an eselect script |
21 |
> allowing to switch from one to an other wxWidgets library version or to |
22 |
> switch from the debug to the release version. This is already supported |
23 |
> by the wx-config utility tool. |
24 |
|
25 |
To a certain extent of "supported". |
26 |
|
27 |
Anyhow, the plan of action for wxWidgets: |
28 |
|
29 |
1) Get two things handled for wxGTK-2.6.3.3 (a patch I need to add for a |
30 |
build fix for some machines and looking if we need to restrict MAKEOPTS |
31 |
to -j1 again) and request stabilization of wxGTK-2.6.3.3 and |
32 |
wxpython-2.6.3.2 (as the current latest stable versions mismatch badly, |
33 |
this is a big improvement - the subrelease [fourth number] mismatch is |
34 |
purely cosmetical, while a mismatch of minor version number can cause |
35 |
real problems) |
36 |
|
37 |
2) Finish up the fixes for wxpython ebuild and add them together with |
38 |
2.6.3.3. Stabilize it at some point. |
39 |
|
40 |
3) Phase out wxGTK and wxpython 2.4 versions. Port or treeclean |
41 |
applications that don't work with 2.4; get rid of 2.4 |
42 |
|
43 |
4) Probably at some point add 2.6.4 - upstream is planning to release it |
44 |
soon for some important bug fixes for applications that haven't ported |
45 |
to 2.8 yet (see bug 151528 for such an example). |
46 |
|
47 |
5) Work towards adding 2.8 to the tree, getting some outstanding |
48 |
problems sorted out together with the new SLOT, most notably file |
49 |
collisions and multi-version handling |
50 |
|
51 |
5a) Patch translation files to be versioned, as to not have collisions |
52 |
from wxstd.mo files, but instead have wxstd-2.8.mo for 2.8 (no need to |
53 |
patch 2.6, as 2.4 is going out and then 2.6 is the only with just |
54 |
wxstd.mo) |
55 |
|
56 |
5b) Introduce an eselect module as you suggested as well. Make it handle |
57 |
the wx-config symlink for users and provide wx-config and wxwin.m4 files |
58 |
from it; perhaps some other files too. Make it block all versions before |
59 |
the new 2.6 and 2.8 versions that depend on it - this also ensures users |
60 |
will unmerge wxGTK-2.4 SLOT out of their system, as it continues causing |
61 |
the problems we are trying to solve. |
62 |
|
63 |
5c) Check the dependencies for apps - ensure that those that have |
64 |
>=wxGTK-2.6 really mean it, and same with =wxGTK-2.6*, and so on |
65 |
|
66 |
5d) Figure out the automatic version selection through wxwin.m4 for |
67 |
applications - they are supposed to all honor what we are doing to |
68 |
select the version, and as such not rely on what the wx-config symlink |
69 |
points at. This way wx-config would become strictly a non-portage thing |
70 |
for convenience, and easy version choosing for self-compiled apps |
71 |
through the eselect module |
72 |
|
73 |
6) Fix the mess that is LDFLAGS handling in wxWidgets configure.in - it |
74 |
adds user set LDFLAGS to wx-config outputs and breakage ensues. To fix |
75 |
it, configure.in should use a different variable for things it adds |
76 |
itself, and use that only for wx-config, while for the compilation of |
77 |
the library both the extra variable and (user set) LDFLAGS would be |
78 |
used. |
79 |
|
80 |
|
81 |
|
82 |
So if you want to help with any of these steps or more (we maintain some |
83 |
apps and other libs too), feel free to discuss this with me. I prefer |
84 |
IRC communication for things like that, but e-mail correspondence is |
85 |
fine too, just slow. I'm leio on irc.freenode.net network. |
86 |
|
87 |
> I will be grateful to anyone who could help me in my intention to become |
88 |
> a gentoo developer or point me to the right place to discuss about. |
89 |
|
90 |
That doesn't sound bad :) |
91 |
We'd have to look a mentor for you then, but I'm sure that will not a |
92 |
problem. |
93 |
For starters we can get things done without developer status though and |
94 |
then at some point I'd be willing to vouch for you, if you do a good |
95 |
job ;) |
96 |
|
97 |
|
98 |
-- |
99 |
Mart Raudsepp |
100 |
Gentoo Developer; wxwindows and gnome herd |
101 |
Mail: leio@g.o |
102 |
Weblog: http://planet.gentoo.org/developers/leio |