On Oct 22, 2012 2:10 PM, "Mike Gilbert" <floppym@gentoo.org> wrote:
>
> On Sun, Oct 21, 2012 at 5:16 AM, Michał Górny <mgorny@gentoo.org> wrote:
> > Hello,
> >
> > Right now, there are two variables which are set per-implementation --
> > PYTHON & EPYTHON. However, one of our users (sorry for not remembering
> > who) requested an ability to get Python libdir, site-packages directory
> > as well. This raises a question on the interface which should be used
> > to get those values.
> >
> > The common interface in Gentoo is to use 'getter' functions. Since bash
> > doesn't have any real concept of return values, those functions use
> > output capturing -- and that involves subshelling which is pretty bad
> > for commonly used functions. An alternative is to use an 'export'
> > function like tc-export() in toolchain-funcs.
> >
> > I'd like to shortly point out advantages and disadvantages of each
> > solution.
> >
> >
> > 1) getter functions
> >    - python_get_PYTHON [<impl>]
> >    - python_get_EPYTHON <impl>
> >    - python_get_sitedir [<impl>]
> >
> > + clear separation between variables
> >   -> especially useful to keep docs clear and short
> >
> > - one subshell (and function call) for each variable, for each
> >   implementation
> >   -> that makes it 2 * n-impls for each phase function in distutils-r1
> >
> >
> > 2) a single export function
> >    - python_export [<impl>] <var>...
> >    e.g. python_export python2_7 PYTHON EPYTHON PYTHON_SITEDIR
> >
> > + no subshelling
> >
> > + multiple variables can be set in a single function call
> >
> > - potential for variable conflicts
> >   -> e.g. when PYTHON_SITEDIR is used differently by the build system,
> >      the ebuild would need to 'move' it (unlikely but possible)
> >
> > - mixing of implementation and variables in parameters (optional first
> >   parameter)
> >   -> technically it's acceptable but looks a bit bad.
> >
> >
> > What are your thoughts?
> >
>
> I think creating sub-shells in sections which are not processed in
> global scope is really not a big deal.
>
> I think the getter functions are more intuitive. However, I also like
> the idea of setting variables at the same time, similar to the way
> this is handled in _tc-getPROG. The result is stored in a variable and
> also echoed, leaving it up to the end user to decide how he wants to
> process it.
>
> So, I vote for getters that emulate the toolchain-funcs behavior.
>
+1 from me too. But lets avoid redundancy in variable names, please.