[Buildroot] [PATCH 04/20 RFC] support/gen-manual-lists.py: rework generating the virtual package list

Yann E. MORIN yann.morin.1998 at free.fr
Sun Jun 15 21:06:17 UTC 2014


Samuel, All,

On 2014-06-15 22:18 +0200, Samuel Martin spake thusly:
> On Sat, Jun 14, 2014 at 1:02 AM, Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
> > From: "Yann E. MORIN" <yann.morin.1998 at free.fr>
[--SNIP a lot of typoes--]

OK, will fix all of those.

> > Signed-off-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>
> > ---
> >  support/scripts/gen-manual-lists.py | 88 +++++++++++++++++++++++++++++++------
> >  1 file changed, 74 insertions(+), 14 deletions(-)
> >
> > diff --git a/support/scripts/gen-manual-lists.py b/support/scripts/gen-manual-lists.py
> > index 95c10dc..837cd66 100644
> > --- a/support/scripts/gen-manual-lists.py
> > +++ b/support/scripts/gen-manual-lists.py
[--SNIP yet another bunch of typoes--]

OK, will fix.

> > +                if parent_pkg is not None:
> > +                    providers_syms_w_opts.append( (parent_pkg,sym) )
> space after ','

I was wondering what was the coding rule when an argument is a tuple.
Usually, we do not have a space after anopening brace, or before a
closing brace. But it looks strange when the (only) arg is a tuple.

Should I write:
    .append( (parent_pkg, sym) )
or:
    .append((parent_pkg, sym))
?

> > +            # Finally, complete with the list of providers without option
> > +            for p in providers_syms:
> > +                if p in seen:
> > +                    continue
> > +                _p = re.sub(r"^BR2_PACKAGE_(.*)", r"\1", p.get_name()).lower()
> > +                providers_str.append(_p)
> hum... here, you _p is the low-case symbol name (without the
> BR2_PACKAGE_ prefix), not exactly the package name (e.g. for
> rpi-userland, you get "rpi_userland",= instead of "rpi-userland"). Or
> am I missing something?

Doh. That's right... Good catch. I'll (try to) fix that.

> > +
> > +            return providers_str
> > +
> > +        # This functions return a list of all symbols that have a prompt,
> > +        # and that 'select' the given symbol
> > +        def _get_selecting_symbols_with_prompt(symbol):
> It's a bit weird to have the definition of this function after you use
> it  (in the previous on), but python allows this ;-)

Well, do we want all functions to be defined before (code-wise) we call
them, or do we prefer to have the important functions come first?

I usually tend to the latter. But I'll move the functions.

Thank you for the reviews! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'


More information about the buildroot mailing list