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

Samuel Martin s.martin49 at gmail.com
Sun Jun 15 21:28:49 UTC 2014


On Sun, Jun 15, 2014 at 11:06 PM, Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
> 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))
> ?

Usually there is no space between the function's brackets and the
tuple's ones, though I'm ok with space since it may improve
readability.

>
>> > +            # 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?

Well, your call ;-)

>
> 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.  |
> '------------------------------^-------^------------------^--------------------'



-- 
Samuel



More information about the buildroot mailing list