On Tue, Nov 9, 2021 at 10:28 AM Petr Nechaev < [email protected]> wrote:
> Hi All, > > I would also emit a (switchable on / off) warning for VAR_append and > VAR:append without a space when VAR contains spaces already i.e.: > > VAR = "opt1 opt2" > VAR:append = "opt3" --> warning > I was just going to comment with the same idea. Much earlier in my OE journey, this bit me often and was a source of confusion. > VAR2 = "--I-have-super-long-custom-option-flag" > VAR2:append = "-and-short-also" --> NO warning > > This should cause very little false warnings. > > --- > Petr > > > On Tue, Nov 9, 2021 at 8:15 PM Quentin Schulz <[email protected]> wrote: > >> Hi Richard, >> >> On November 9, 2021 4:15:16 PM GMT+01:00, Richard Purdie < >> [email protected]> wrote: >> >Hi All, >> > >> >I shared a patch on the bitbake mailing list to make some syntax generate >> >warnings, specifically things of the form: >> > >> >XXX_append += "YYY" >> >XXX_prepend += "YYY" >> >XXX_remove += "YYY" >> > >> >> Using the old syntax :D? >> >> >and the ?=, =+, .= and =. variants. This also covers variants with >> overrides in >> >there too. It would basically mean that you need to use "=" with the >> append >> >operator and friends. >> > >> >We found one reference of that use in OE-Core and one in meta-intel. >> There are >> >others in other layers but the usage isn't that widespread. >> > >> >Why should we warn against this? The += usage in particular is sometimes >> used to >> >add a space so: >> > >> >XXX_append += "YYY" >> > >> >and >> > >> >XXX_append = " YYY" >> > >> >are equivalent but this is more of an accident rather than a specific >> bitbake >> >design. It is extremely confusing to new users and has been complained >> about >> >before as an issue effecting usability. New users often think that += >> will stack >> >the append strings much like += does on a normal variable but that is >> not the >> >case and can lead to confusion. >> > >> >I'm been looking at ways we can simplify without hurting functionality >> and >> >having this slightly obscure usage doesn't really seem to help much. If >> we agree >> >to do this, I would make it an error in due course after users have seen >> the >> >warnings for a while. I'd probably want to do that before the LTS next >> year. >> > >> >> I'm all for removing potential areas of confusion, so +1. >> >> On that topic, if I'm not mistaken, the same applies to: >> >> FOO:.*{append, prepend, remove}:.*{append,prepend,remove} >> ? Basically it does not make much sense to have (any) two of append, >> prepend, remove as overrides of the same variable (on the same line). >> >> Cheers, >> Quentin >> >> >Cheers, >> > >> >Richard >> > >> > >> > >> > >> >> >> >> > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1348): https://lists.openembedded.org/g/openembedded-architecture/message/1348 Mute This Topic: https://lists.openembedded.org/mt/86933270/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
