1 |
On Oct 22, 2012 2:10 PM, "Mike Gilbert" <floppym@g.o> wrote: |
2 |
> |
3 |
> On Sun, Oct 21, 2012 at 5:16 AM, Michał Górny <mgorny@g.o> wrote: |
4 |
> > Hello, |
5 |
> > |
6 |
> > Right now, there are two variables which are set per-implementation -- |
7 |
> > PYTHON & EPYTHON. However, one of our users (sorry for not remembering |
8 |
> > who) requested an ability to get Python libdir, site-packages directory |
9 |
> > as well. This raises a question on the interface which should be used |
10 |
> > to get those values. |
11 |
> > |
12 |
> > The common interface in Gentoo is to use 'getter' functions. Since bash |
13 |
> > doesn't have any real concept of return values, those functions use |
14 |
> > output capturing -- and that involves subshelling which is pretty bad |
15 |
> > for commonly used functions. An alternative is to use an 'export' |
16 |
> > function like tc-export() in toolchain-funcs. |
17 |
> > |
18 |
> > I'd like to shortly point out advantages and disadvantages of each |
19 |
> > solution. |
20 |
> > |
21 |
> > |
22 |
> > 1) getter functions |
23 |
> > - python_get_PYTHON [<impl>] |
24 |
> > - python_get_EPYTHON <impl> |
25 |
> > - python_get_sitedir [<impl>] |
26 |
> > |
27 |
> > + clear separation between variables |
28 |
> > -> especially useful to keep docs clear and short |
29 |
> > |
30 |
> > - one subshell (and function call) for each variable, for each |
31 |
> > implementation |
32 |
> > -> that makes it 2 * n-impls for each phase function in distutils-r1 |
33 |
> > |
34 |
> > |
35 |
> > 2) a single export function |
36 |
> > - python_export [<impl>] <var>... |
37 |
> > e.g. python_export python2_7 PYTHON EPYTHON PYTHON_SITEDIR |
38 |
> > |
39 |
> > + no subshelling |
40 |
> > |
41 |
> > + multiple variables can be set in a single function call |
42 |
> > |
43 |
> > - potential for variable conflicts |
44 |
> > -> e.g. when PYTHON_SITEDIR is used differently by the build system, |
45 |
> > the ebuild would need to 'move' it (unlikely but possible) |
46 |
> > |
47 |
> > - mixing of implementation and variables in parameters (optional first |
48 |
> > parameter) |
49 |
> > -> technically it's acceptable but looks a bit bad. |
50 |
> > |
51 |
> > |
52 |
> > What are your thoughts? |
53 |
> > |
54 |
> |
55 |
> I think creating sub-shells in sections which are not processed in |
56 |
> global scope is really not a big deal. |
57 |
> |
58 |
> I think the getter functions are more intuitive. However, I also like |
59 |
> the idea of setting variables at the same time, similar to the way |
60 |
> this is handled in _tc-getPROG. The result is stored in a variable and |
61 |
> also echoed, leaving it up to the end user to decide how he wants to |
62 |
> process it. |
63 |
> |
64 |
> So, I vote for getters that emulate the toolchain-funcs behavior. |
65 |
> |
66 |
+1 from me too. But lets avoid redundancy in variable names, please. |