subtle weirdness when you combine "_append" with "+="?

subtle weirdness when you combine "_append" with "+="?

[Robert P. J. Day]

  was about to submit a small number of patches to clean up redundancy
when people combine "_append" with "+=" (because it offends my
delicate sensibilities), and ran across this in oe-core,
unfs3_0.9.22.r497.bb:

  DEPENDS_append_class-nativesdk += "flex-nativesdk"

uh, what?

  most of the time, i assume the above doesn't hurt, it's just ...
silly. but normally, with "_append", you *need* to add the leading
space explicitly, and that's not being done above. so does that mean
that combining "_append" with "+=" *does* generate a leading space?
that just makes my head hurt -- the possibility that "_append" is
being used in a way that normally makes it fail, only to have "+="
step in and save the day. at which point "_append" saves processing
that until the end of parsing? yeesh.

  thoughts?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: subtle weirdness when you combine "_append" with "+="?

[Ulf Magnusson]

On Tue, Aug 16, 2016 at 4:02 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>   was about to submit a small number of patches to clean up redundancy
> when people combine "_append" with "+=" (because it offends my
> delicate sensibilities), and ran across this in oe-core,
> unfs3_0.9.22.r497.bb:
>
>   DEPENDS_append_class-nativesdk += "flex-nativesdk"
>
> uh, what?
>
>   most of the time, i assume the above doesn't hurt, it's just ...
> silly. but normally, with "_append", you *need* to add the leading
> space explicitly, and that's not being done above. so does that mean
> that combining "_append" with "+=" *does* generate a leading space?
> that just makes my head hurt -- the possibility that "_append" is
> being used in a way that normally makes it fail, only to have "+="
> step in and save the day. at which point "_append" saves processing
> that until the end of parsing? yeesh.
>
>   thoughts?

By the point the += is handled, the override won't have been interpreted
yet. My guess is that += fetches the value of the variable
"DEPENDS_append_class-nativesdk", gets back the empty string, and
adds a space followed by "flex-nativesdk" to that.

The resulting " flex-nativesdk" is then interpreted as usual when the
overrides are handled.

You might like the note I added to
https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#override-style-operation-advantages
by the way. :)

Cheers,
Ulf

Re: subtle weirdness when you combine "_append" with "+="?

[Robert P. J. Day]

On Tue, 16 Aug 2016, Ulf Magnusson wrote:

> On Tue, Aug 16, 2016 at 4:02 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >
> >   was about to submit a small number of patches to clean up redundancy
> > when people combine "_append" with "+=" (because it offends my
> > delicate sensibilities), and ran across this in oe-core,
> > unfs3_0.9.22.r497.bb:
> >
> >   DEPENDS_append_class-nativesdk += "flex-nativesdk"
> >
> > uh, what?
> >
> >   most of the time, i assume the above doesn't hurt, it's just ...
> > silly. but normally, with "_append", you *need* to add the leading
> > space explicitly, and that's not being done above. so does that mean
> > that combining "_append" with "+=" *does* generate a leading space?
> > that just makes my head hurt -- the possibility that "_append" is
> > being used in a way that normally makes it fail, only to have "+="
> > step in and save the day. at which point "_append" saves processing
> > that until the end of parsing? yeesh.
> >
> >   thoughts?
>
> By the point the += is handled, the override won't have been interpreted
> yet. My guess is that += fetches the value of the variable
> "DEPENDS_append_class-nativesdk", gets back the empty string, and
> adds a space followed by "flex-nativesdk" to that.
>
> The resulting " flex-nativesdk" is then interpreted as usual when the
> overrides are handled.
>
> You might like the note I added to
> https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#override-style-operation-advantages
> by the way. :)

  that note is pretty much what i've been whining about for a long
time. :-) in any event, when one sees something like the above:

  DEPENDS_append_class-nativesdk += "flex-nativesdk"

what is the *proper* cleanup?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: subtle weirdness when you combine "_append" with "+="?

[Ulf Magnusson]

On Tue, Aug 16, 2016 at 5:49 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Tue, 16 Aug 2016, Ulf Magnusson wrote:
>
>> On Tue, Aug 16, 2016 at 4:02 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>> >
>> >   was about to submit a small number of patches to clean up redundancy
>> > when people combine "_append" with "+=" (because it offends my
>> > delicate sensibilities), and ran across this in oe-core,
>> > unfs3_0.9.22.r497.bb:
>> >
>> >   DEPENDS_append_class-nativesdk += "flex-nativesdk"
>> >
>> > uh, what?
>> >
>> >   most of the time, i assume the above doesn't hurt, it's just ...
>> > silly. but normally, with "_append", you *need* to add the leading
>> > space explicitly, and that's not being done above. so does that mean
>> > that combining "_append" with "+=" *does* generate a leading space?
>> > that just makes my head hurt -- the possibility that "_append" is
>> > being used in a way that normally makes it fail, only to have "+="
>> > step in and save the day. at which point "_append" saves processing
>> > that until the end of parsing? yeesh.
>> >
>> >   thoughts?
>>
>> By the point the += is handled, the override won't have been interpreted
>> yet. My guess is that += fetches the value of the variable
>> "DEPENDS_append_class-nativesdk", gets back the empty string, and
>> adds a space followed by "flex-nativesdk" to that.
>>
>> The resulting " flex-nativesdk" is then interpreted as usual when the
>> overrides are handled.
>>
>> You might like the note I added to
>> https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#override-style-operation-advantages
>> by the way. :)
>
>   that note is pretty much what i've been whining about for a long
> time. :-) in any event, when one sees something like the above:

The intent of the note was to discourage use of '+=' together with _append,
because it's redundant and potentially confusing. Do you think it fails
(even in context)? :/

>
>   DEPENDS_append_class-nativesdk += "flex-nativesdk"
>
> what is the *proper* cleanup?

I'd say the following:

DEPENDS_append_class-nativesdk = " flex-nativesdk"

Cheers,
Ulf

Re: subtle weirdness when you combine "_append" with "+="?

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]


> On Aug 16, 2016, at 8:56 AM, Ulf Magnusson <ulfalizer@gmail.com> wrote:
> 
> On Tue, Aug 16, 2016 at 5:49 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>> On Tue, 16 Aug 2016, Ulf Magnusson wrote:
>> 
>>> On Tue, Aug 16, 2016 at 4:02 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>>>> 
>>>>  was about to submit a small number of patches to clean up redundancy
>>>> when people combine "_append" with "+=" (because it offends my
>>>> delicate sensibilities), and ran across this in oe-core,
>>>> unfs3_0.9.22.r497.bb:
>>>> 
>>>>  DEPENDS_append_class-nativesdk += "flex-nativesdk"
>>>> 
>>>> uh, what?
>>>> 
>>>>  most of the time, i assume the above doesn't hurt, it's just ...
>>>> silly. but normally, with "_append", you *need* to add the leading
>>>> space explicitly, and that's not being done above. so does that mean
>>>> that combining "_append" with "+=" *does* generate a leading space?
>>>> that just makes my head hurt -- the possibility that "_append" is
>>>> being used in a way that normally makes it fail, only to have "+="
>>>> step in and save the day. at which point "_append" saves processing
>>>> that until the end of parsing? yeesh.
>>>> 
>>>>  thoughts?
>>> 
>>> By the point the += is handled, the override won't have been interpreted
>>> yet. My guess is that += fetches the value of the variable
>>> "DEPENDS_append_class-nativesdk", gets back the empty string, and
>>> adds a space followed by "flex-nativesdk" to that.
>>> 
>>> The resulting " flex-nativesdk" is then interpreted as usual when the
>>> overrides are handled.
>>> 
>>> You might like the note I added to
>>> https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#override-style-operation-advantages
>>> by the way. :)
>> 
>>  that note is pretty much what i've been whining about for a long
>> time. :-) in any event, when one sees something like the above:
> 
> The intent of the note was to discourage use of '+=' together with _append,
> because it's redundant and potentially confusing. Do you think it fails
> (even in context)? :/

the _append/_prepend in conjunction with += is a undocumented behavior
however, I do not see it as much a side effect. But in future bitbake may
silently change its behavior, so I agree its always good to stay in safe
waters.

> 
>> 
>>  DEPENDS_append_class-nativesdk += "flex-nativesdk"
>> 
>> what is the *proper* cleanup?
> 
> I'd say the following:
> 
> DEPENDS_append_class-nativesdk = " flex-nativesdk"
> 
> Cheers,
> Ulf
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: subtle weirdness when you combine "_append" with "+="?

[Robert P. J. Day]

On Tue, 16 Aug 2016, Khem Raj wrote:

  ... big snip ...

> the _append/_prepend in conjunction with += is a undocumented
> behavior however, I do not see it as much a side effect. But in
> future bitbake may silently change its behavior, so I agree its
> always good to stay in safe waters.

  so just to finalize this discussion, my thoughts on a reasonable and
meaningful standard for append/prepend/etc/etc would be to *always*
use the "mathematical" operators +=/.=/=+/=. except in two situations:

  1) when parsing *must* be delayed until the end, or
  2) when combining the operation with an override (for which i'm
     quite sure there is no equivalent when using +=, etc, right?)

i'm a big fan of simplicity, in the sense that, if an append operation
does not *require* "_append", it shouldn't use it. because if i see an
expression:

  VAR_append = "..."

then i immediately wonder if there is a *reason* for using "_append"
rather than "+=" or ".=", or if that is just the developer's personal
preference. and i really, really, really hate having to guess.

  oh, and of course, never, ever combine "_append" with "+=" or ".=".
does that sound like a reasonable coding style?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: subtle weirdness when you combine "_append" with "+="?

[Ulf Magnusson]

On Wed, Aug 17, 2016 at 3:21 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Tue, 16 Aug 2016, Khem Raj wrote:
>
>   ... big snip ...
>
>> the _append/_prepend in conjunction with += is a undocumented
>> behavior however, I do not see it as much a side effect. But in
>> future bitbake may silently change its behavior, so I agree its
>> always good to stay in safe waters.
>
>   so just to finalize this discussion, my thoughts on a reasonable and
> meaningful standard for append/prepend/etc/etc would be to *always*
> use the "mathematical" operators +=/.=/=+/=. except in two situations:
>
>   1) when parsing *must* be delayed until the end, or

I agree as long as that *must* also includes the kind of situation
described for foo.bbclass in
https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#override-style-operation-advantages.
I think you ought to follow the principle of least surprise.

>   2) when combining the operation with an override (for which i'm
>      quite sure there is no equivalent when using +=, etc, right?)
>
> i'm a big fan of simplicity, in the sense that, if an append operation
> does not *require* "_append", it shouldn't use it. because if i see an
> expression:
>
>   VAR_append = "..."
>
> then i immediately wonder if there is a *reason* for using "_append"
> rather than "+=" or ".=", or if that is just the developer's personal
> preference. and i really, really, really hate having to guess.
>
>   oh, and of course, never, ever combine "_append" with "+=" or ".=".
> does that sound like a reasonable coding style?

Sounds reasonable to me. Using _append rather than += can also be
a bug in certain situations. For example, the following does not
guarantee that " value1 value2" appears right after "--flag":

FLAGS = "--flag"
FLAGS_append = " value1"
FLAGS_append = " value2"

Any earlier FLAGS_append value would appear before those two.

Cheers,
Ulf

Re: subtle weirdness when you combine "_append" with "+="?

[Robert P. J. Day]

On Wed, 17 Aug 2016, Ulf Magnusson wrote:

> On Wed, Aug 17, 2016 at 3:21 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > On Tue, 16 Aug 2016, Khem Raj wrote:
> >
> >   ... big snip ...
> >
> >> the _append/_prepend in conjunction with += is a undocumented
> >> behavior however, I do not see it as much a side effect. But in
> >> future bitbake may silently change its behavior, so I agree its
> >> always good to stay in safe waters.
> >
> >   so just to finalize this discussion, my thoughts on a reasonable and
> > meaningful standard for append/prepend/etc/etc would be to *always*
> > use the "mathematical" operators +=/.=/=+/=. except in two situations:
> >
> >   1) when parsing *must* be delayed until the end, or
>
> I agree as long as that *must* also includes the kind of situation
> described for foo.bbclass in
> https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#override-style-operation-advantages.
> I think you ought to follow the principle of least surprise.

  agreed. i guess a simpler way to state it is that one should never
use "_append" unless it's necessary. that pretty much covers all
situations.

> >   2) when combining the operation with an override (for which i'm
> >      quite sure there is no equivalent when using +=, etc, right?)
> >
> > i'm a big fan of simplicity, in the sense that, if an append operation
> > does not *require* "_append", it shouldn't use it. because if i see an
> > expression:
> >
> >   VAR_append = "..."
> >
> > then i immediately wonder if there is a *reason* for using "_append"
> > rather than "+=" or ".=", or if that is just the developer's personal
> > preference. and i really, really, really hate having to guess.
> >
> >   oh, and of course, never, ever combine "_append" with "+=" or ".=".
> > does that sound like a reasonable coding style?
>
> Sounds reasonable to me. Using _append rather than += can also be
> a bug in certain situations. For example, the following does not
> guarantee that " value1 value2" appears right after "--flag":
>
> FLAGS = "--flag"
> FLAGS_append = " value1"
> FLAGS_append = " value2"
>
> Any earlier FLAGS_append value would appear before those two.

  i don't see that as a "bug"; it's exactly the way it *should*
operate. the above is more an example of someone not *understanding*
how those operators work.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================