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 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 (#1347): https://lists.openembedded.org/g/openembedded-architecture/message/1347 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]] -=-=-=-=-=-=-=-=-=-=-=-
