[oe] RFC: strip "-native" from $S for native packages automatically (bug 1856)

[Paul Sokolovsky]

Hello Richard,

Sunday, January 27, 2008, 2:23:27 AM, you wrote:

> On Sat, 2008-01-26 at 13:43 +0000, Richard Purdie wrote:
>> On Sat, 2008-01-26 at 01:51 +0100, Michael 'Mickey' Lauer wrote:
>> > If we really want to have that (I'm -0 on that), I would rather propose
>> > 
>> > S = ${@"%s/%s" % ( bb.data.getVar("WORKDIR", d, 1), bb.data.getVar("P", d, 1).replace( "-native", "" ) ) }
>> 
>> Would it be worth adding syntax to bitbake for this kind of operation,
>> something like:
>> 
>> S *= "${S}-native"
>> 
>> ?

> This syntax doesn't solve the original problem of course.

> People have requested -= and I've been wondering if we should add that
> as a search and remove operator. To match the existing language that
> would have to work on space delimited lists though so its of no use to
> this use case. We could pair this with a *= or operator which worked the
> same way without the space delimiter like .= does...

> S *= "-native"

> ?

> maybe ~= would be a better pairing with -=?

  I personally don't like this operator obfuscation, which becomes
just that once obscure symbol combinations are used or well-known
operators from other languages are reused with different semantics.
All that will lead to very that Perl's $@#%&* stuff.

> Having syntax which allowed variable reuse like the original example
> above could also be useful:

> S = "foo"
> S *= "${S}-native"
> print bb.data.getVar("S", d, 1)
>     foo-native

> Does anyone have any other language enhancement requests for bitbake
> while I'm thinking about it (or any thoughts on the above)?

  Yes, I have. Those 'bb.data.getVar("S", d, 1)' looks quite
unaesthetically and brings thought that Python expression support is a
quick hack. Instead, it should be something like:

d2.get("S")
d2.get("S", expand = 0)

  Note the default for expanded grounded in common use.

  Stuff above could be then:

d2.get("S").replace("-native", "")

> Cheers,

> Richard


-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com