Hi Rasmus, On Fri, 22 Oct 2021 at 00:41, Rasmus Villemoes <rasmus.villem...@prevas.dk> wrote: > > On 21/10/2021 18.03, Tom Rini wrote: > > On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote: > >> Hi Marek, > >> > >> On Thu, 21 Oct 2021 at 07:28, Marek Behún <marek.be...@nic.cz> wrote: > >>> > >>> On Thu, 21 Oct 2021 15:25:37 +0200 > >>> Marek Behún <marek.be...@nic.cz> wrote: > >>> > >>>> Hello, > >>>> > >>>> On Thu, 21 Oct 2021 15:06:51 +0200 > >>>> Wolfgang Denk <w...@denx.de> wrote: > >>>> > >>>>> I confirm that '+=' looks better. But '+=" is technically broken. > >>>> > >>>> a bit of my opinion: > >>>> I think =+ will confuse far more people than + as last character of var > >>>> name working weirdly. But I also think that + should be supported as > >>>> last character. Therefore I propose backslash escaping in variable name, > >>>> i.e. > >>>> var+=value > >>>> appends value to var, while > >>>> var\+=value > >>>> sets variable with name "var+" > >> > >> My first preference is to disallow + at the end of an end var. Perhaps > >> we can start printing a warning if people do it, for a few releases. > >> > >> My distance second preference is what Marek has here, using a > >> backslash to escape the + character. > > > > How bad does it make the parser look if we allow trailing + in variable > > names, by escaping them? It's seemingly the substantive objection at > > this point. > > > > So I don't understand all the bruhahaha around a + at the end of the > varname. Nobody suggests (that I have seen) changing anything about how > U-Boot at runtime interprets and handles variables, so all variable > names that used to be valid continue to be so. > > It's just that this _new_ method of generating the environment places > certain restrictions on what can be done. The old-fashioned ways > (mkenvimage, good'ol CONFIG_ENV_EXTRA_SETTINGS with all its warts, and > run-time 'env set') continue to allow people to define whatever env vars > they want. This new method is meant for transitioning in-tree boards' > default environment, and no in-tree boards need anything exotic. > > Also, completely independent of whether the subsequent parser is > implemented in awk or python or rust, or what syntax it accepts and the > semantics of that syntax, the fact that we first pass the input through > cpp already means some things just won't work the same way as when given > to mkenvimage, and that applies to both sides of the =: > > printf 'x/* huh */y=/* where did this go ? */\nmsg=I like unix\nfive > spaces=5spaces\n' | gcc -E -P -x assembler-with-cpp - > > x y= > msg=I like 1 > five spaces=5spaces > > [In case its broken by the email, there are actually five spaces in the > printf string between the words "five" and "spaces", the above should > illustrate that cpp collapses those to a single space]. > > So, I'd much rather we do a cleaner break, and accept (and ignore) > whitespace on either side of the assignment operator - that's how Make > variable assignments work IIRC. And since a lot of people making use of > this will already be familiar with Yocto, I think we should have two > compound assignment operators, .= and +=. That still allows one to use > any non-whitespace, non-= characters (modulo the restrictions imposed by > the whole thing passing through cpp) in variable names, so > > foo+=abc > > means > > foo+ = abc > > while could append to foo by saying > > foo += abc > > That whitespace around the assignment operators would also make the > input files somewhat more readable - there really is no point in having > human-readable, human-editable text files having a format > almost-but-not-quite be that of the on-disk format.
I am OK with this on the name front, as I assume we don't want to allow space in a var name! But how do I do this? bootargs=console=fred #ifdef SOMETHING bootargs+= dm-verity=... #endif We need the space between the bootargs. Regards, Simon