1 |
Mart Raudsepp wrote: |
2 |
> Hello, |
3 |
> |
4 |
> On E, 2007-09-24 at 21:14 -0600, Ryan Hill wrote: |
5 |
>> since everyone is getting into the reviewing mood, i thought it |
6 |
>> would be a good time to get some opinions on the wxwidgets |
7 |
>> eclass rewrite i've done. |
8 |
> |
9 |
> |
10 |
> I figured I'd reply to the old review request on the list instead of |
11 |
> doing this privately, so here we go. |
12 |
> |
13 |
> The notes are based on the latest eclass located at |
14 |
> http://overlays.gentoo.org/dev/dirtyepic/browser/eclass/wxwidgets.eclass |
15 |
> at current revision 6: |
16 |
> |
17 |
> * I just assume the documentation markup for the new way of doing eclass |
18 |
> documenting is good. The documentation text itself seems mostly good, if |
19 |
> maybe not so professional. Some nitpicking: |
20 |
|
21 |
Bah, professionalism is for professionals. ;) |
22 |
|
23 |
> ** Ebuilds are also required set the global -> s/required/required to/? |
24 |
|
25 |
Yep. |
26 |
|
27 |
> ** The description gives the impression we support installation of |
28 |
> release/debug side-by-side - don't think this is true. Maybe we should |
29 |
> think about a way for users to be able to set their own wx-config to a |
30 |
> debug build, but have the system USE flag dependent. Hmm... Maybe I |
31 |
> should revise my stance on debug + release co-existance in some form |
32 |
|
33 |
This is basically what I had previously (though much uglier). I figured |
34 |
we might want to rethink it later so I made it simple to re-add again if |
35 |
we want. For now though I'd just like to get this out to the public. |
36 |
|
37 |
> ** Once 2.8 is in, we should update the simple usage example to that |
38 |
|
39 |
For sure. |
40 |
|
41 |
> ** With EAPI=1 SLOT depends can be used now, but as wx is always with a |
42 |
> version and SLOT matching a way that * wildcard can be used, it's fine |
43 |
> to not require things to use EAPI=1 indeed I'd say. Just noting. |
44 |
|
45 |
With EAPI=1 we can also do something like |
46 |
|
47 |
DEPEND=">=x11-libs/wxGTK-2.6.2:2.6" |
48 |
|
49 |
which neatly solves our issue with needing a minimum version in a SLOT. |
50 |
|
51 |
I'll make a note of this in the documentation. |
52 |
|
53 |
> ** In simple usage example I would rather refer to RDEPEND, not DEPEND, |
54 |
> or both |
55 |
|
56 |
Hmm? RDEPEND defaults to DEPEND if not defined but not the other way |
57 |
around. I will refer to both though since wxGTK does definitely need |
58 |
to be in RDEPEND for proper binpkgs. |
59 |
|
60 |
> * Perhaps we should take care of setting the wxGTK DEPEND and RDEPEND |
61 |
> ourselves based on a WX_GTK_VER in ebuilds global scope? Might cause |
62 |
> problems for things using wx conditionally for some optional GUI. |
63 |
> Talking of which, it seems it already relies on global scope - does that |
64 |
> work fine with conditional wx usage? need-wxwidgets for that, I guess? |
65 |
> What's the view on eclasses touching DEPEND/RDEPEND these days, anyway? |
66 |
|
67 |
I believe this would force everything with an optional wxwidgets USE flag |
68 |
to require wxGTK. I never really thought about how the global code affects |
69 |
the conditional case until now, but considering that all it does is set a |
70 |
variable if wxGTK is installed it would seem that it could take advantage |
71 |
of it as well and only call need-wxwidgets if it needs something other than |
72 |
the default. Course calling need-wxwidgets is still a good idea. |
73 |
|
74 |
> * Taking care of DEPEND and RDEPEND in the eclass itself could allow us |
75 |
> to migrate things over to wxBase package in the future without any |
76 |
> ebuild migration work, once we fix upstream configure.in to work with a |
77 |
> system provided wxBase libraries and not have file collisions. However |
78 |
> this probably requires a global variable for base-ansi/base-unicode |
79 |
> passing instead of a need-wxwidgets function for that to be possible to |
80 |
> work out |
81 |
|
82 |
Yes, that would be a future goal. |
83 |
|
84 |
> * I hate any unconditional compiler flags workarounds, such as |
85 |
> "append-flags -fno-strict-aliasing". I have some long pending upstream |
86 |
> work to do to simply fix it in that one header where it makes noise and |
87 |
> once that finally gets resolved (or maybe it already is in 2.8), we have |
88 |
> no reason to keep passing this, as to my knowledge it also means less |
89 |
> optimization chances for gcc. Do we have a plan on how to get rid of |
90 |
> that CFLAGS append once the user is dealing with a wx library that has |
91 |
> this fixed? |
92 |
|
93 |
I believe I added that due to an aliasing bug in the gcc-4.2.0 prerelease. |
94 |
I think I've since gotten the patch applied to our GCC though so it |
95 |
shouldn't be a problem to remove. If we could silence that warning all the |
96 |
better. |
97 |
|
98 |
> At least this isn't the configure argument mess we used to have in |
99 |
> wxlib.eclass where you'd get some important class configured out just |
100 |
> because it was broken in an old version :) |
101 |
> |
102 |
> * Are you sure we want to ewarn unconditionally on all need-wxwidgets |
103 |
> function calls? |
104 |
|
105 |
Right, that should be an einfo. It was originally for debugging but I |
106 |
found it to be pretty useful in practice. |
107 |
|
108 |
> * What's with the TODO on _wxerror() and the function? |
109 |
|
110 |
I thought a broken out error reporting function would save a bunch of |
111 |
duplicated code, but I ended up with a lot fewer cases than I thought |
112 |
I would. I think I might just remove it. |
113 |
|
114 |
> The previous points encompass mostly only things noted while going over |
115 |
> the code - I have yet to look at it with a logic and interaction sense. |
116 |
> I figured I'll get this current list off my hands before I get sunk into |
117 |
> work. |
118 |
> |
119 |
> |
120 |
> Many many thanks for pushing wxGTK forwards while I'm occupied with |
121 |
> work, gnome stuff... and procrastinating |
122 |
|
123 |
Thanks for looking at it. I know you have a lot on your plate. |
124 |
|
125 |
-- |
126 |
fonts / wxWindows / gcc-porting / treecleaners |
127 |
EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) |
128 |
-- |
129 |
gentoo-dev@g.o mailing list |