[U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file

[Wolfgang Denk]

Dear Simon,

In message <CAPnjgZ3tGwRK2ytm59EKUmAiPD5kAq39Mu9BityL0Y6d0H2C1w at mail.gmail.com> you wrote:
>
> > Agreed.  But that's what "env export -t" creates anyway (and I cannot
> > think of a much better presentation of multiline variable content if
> > you don't want to run in ambiguities).
> 
> I believe the ambiguities are pretty rare. And people tend to indent
> multi-line scripts anyway, right?

Do they? In the current include/config/*.h files, there is basically
zero structuring of the environment as nobody has been using
multi-line variables yet.   Yes, there is indentation in the header
files, but this is not visible at all in the environment variables.

> > I don't understand this question here.  I agree that we should be able
> > to run the file through the preprocessor such that it can resolve such
> > macro definitions.  But this should be independent of the actual text
> > format, or am I missing something?
> 
> Yes we can, agreed. I was thinking you would not want the preprocessor
> since 'env export -t' doesn't understand it.

Well, of course it deosn't, as it cannot invert the operation of the C
preprocessor...  But we can still use the prepro to create output that
is digestable to "env import -t", right?

> > Well, I can't see how you avoid such ambiguities in your proposed
> > format.  You need a clear termination for the value of a variable.
> > If it is spread across multiple lines, you have to find a way to mark
> > continuation lines.  The "accepted standard" way to do so is by using
> > a backslash at the end of the line.  It appears you want to use
> > indentation instead - this prevents users from using a free text
> > format, and quickly becomes messy.  And it is incompatible to
> > (current) U-Boot code.
> 
> Indentation is pretty normal in code, so I don't feel embarrassed about
> asking for it. I think the primary problem with my feature is that it is
> different from 'env export -t', and thus potentially introduces another
> format. My argument against that interpretation is that I am in fact
> replacing a C header file definition with a text file, so perhaps I'm not
> really increasing the number of formats?

Well, I'm afraid you have not yet formally defined the syntax of your
format, so I may just misunderstand what you mean.

> Well yes I could adjust 'env export -t' to use the same format - is that a
> good idea, or not? I can see down-sides. We can of course convert existing
> files brought in by 'env import -t' (by making the import flexible) but I
> worry that there might be external tools that users have which expect the
> format to be a certain way.

Are there any such tools?  Anybodyu who is using such please speak up
now and here! ;-)

> I agree creating a new format is not ideal - it's just that the existing C
> header format is so painful...

Yes, I agree on that, and I'm more than willing to get rid of it.  But
it has to be something that is actually working, and that is easy to
work with.

> --485b3970d160c06fb304e9d48797
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">Hi Wolfgang,<br><br>On Mon, Oct 28, 2013 at 3:16 PM, Wolfg=
> ang Denk &lt;<a href=3D"mailto:wd at denx.de">wd at denx.de</a>&gt; wrote:<br>&gt=
...


Argh... can you please turn this off?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I have never understood the female capacity to avoid a direct  answer
to any question.
	-- Spock, "This Side of Paradise", stardate 3417.3