1 |
On Sun, 24 Jun 2012 16:34:55 +0800 |
2 |
Ben de Groot <yngwin@g.o> wrote: |
3 |
|
4 |
> On 24 June 2012 01:57, Michał Górny <mgorny@g.o> wrote: |
5 |
> > On Sun, 24 Jun 2012 03:37:59 +1000 |
6 |
> > Michael Palimaka <kensington@g.o> wrote: |
7 |
> > |
8 |
> >> --- cmake-utils.eclass |
9 |
> >> +++ cmake-utils.eclass |
10 |
> >> @@ -20,0 +21,29 @@ |
11 |
> >> +# @ECLASS-VARIABLE: LANGS |
12 |
> > |
13 |
> > Please prefix. |
14 |
> > |
15 |
> >> +# @DEFAULT_UNSET |
16 |
> >> +# @DESCRIPTION: |
17 |
> >> +# In case your application provides various translations, use this |
18 |
> >> variable to specify |
19 |
> >> +# them in order to populate "linguas_*" IUSE automatically. Make |
20 |
> >> sure that you set this |
21 |
> >> +# variable before inheriting cmake-utils eclass. |
22 |
> >> +# Example: |
23 |
> >> +# @CODE |
24 |
> >> +# LANGS="en el de" |
25 |
> >> +# @CODE |
26 |
> >> +for x in ${LANGS}; do |
27 |
> >> + IUSE+=" linguas_${x}" |
28 |
> >> +done |
29 |
> >> + |
30 |
> >> +# @ECLASS-VARIABLE: LANGSLONG |
31 |
> >> +# @DEFAULT_UNSET |
32 |
> >> +# @DESCRIPTION: |
33 |
> >> +# Same as above, but this variable is for LINGUAS that must be in |
34 |
> >> long format. |
35 |
> >> +# Remember to set this variable before inheriting cmake-utils |
36 |
> >> eclass. +# Look at ${PORTDIR}/profiles/desc/linguas.desc for |
37 |
> >> details. +# Example: |
38 |
> >> +# @CODE |
39 |
> >> +# LANGS="de_DE hu_HU" |
40 |
> >> +# @CODE |
41 |
> > |
42 |
> > Shouldn't this be LANGSLONG? |
43 |
> > |
44 |
> >> +for x in ${LANGSLONG}; do |
45 |
> >> + IUSE+=" linguas_${x%_*}" |
46 |
> >> +done |
47 |
> >> +unset x |
48 |
> >> + |
49 |
> > |
50 |
> > And how does it exactly differ from LANGS above? Is there a reason |
51 |
> > those two can't be coerced into a single variable? |
52 |
> |
53 |
> Some linguas correspond 1:1 between the package and portage's |
54 |
> linguas.desc, while others need the long form (e.g. el_GR) for the |
55 |
> package, but the short form (el) is used in portage. |
56 |
|
57 |
Ah, I see. I was confused because the code doesn't use these vars |
58 |
anywhere else. |
59 |
|
60 |
> > Shouldn't those do something more than setting IUSE? For example, |
61 |
> > actually ensuring those LINGUAS will be installed? |
62 |
> |
63 |
> That would be a nice improvement. |
64 |
> |
65 |
> We at qt@ have been discussing this on and off. We would like to |
66 |
> see a linguas.eclass happen, because already now we start having |
67 |
> code duplication. So instead of this duplication of code between |
68 |
> qt4-r2 and cmake-utils eclasses, why not put this into a separate |
69 |
> linguas.eclass that both can inherit? |
70 |
|
71 |
Yes, it's a much better idea than keeping two copies in sync. |
72 |
|
73 |
> Obviously the problem with handling more than just setting IUSE |
74 |
> is the variety of ways in which linguas are handled by different |
75 |
> packages and different build systems. |
76 |
|
77 |
Yes, that's one problem. Certainly, those flags have to be handled |
78 |
by the build system and the disabled LINGUAS should not be built |
79 |
at all. If there are built already, there's no point in removing them |
80 |
later. |
81 |
|
82 |
Of course, another question is whether LINGUAS does actually benefit |
83 |
users. If compiling another .po files takes a lot of time, probably |
84 |
yes. If it doesn't, I would think about getting rid of that and just |
85 |
installing everything. Additional removal can be handled through |
86 |
INSTALL_MASK. |
87 |
|
88 |
-- |
89 |
Best regards, |
90 |
Michał Górny |