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

[Simon Glass]

Hi Wolfgang,

On Mon, Oct 28, 2013 at 3:16 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon,
>
> In message <CAPnjgZ0+35Zd6_o=G0=
G-YL_mR-GiTW+MeYqK7BSxU_nVkvv1w at mail.gmail.com> you wrote:
>>
>> > I can see why you like such a "beautified" text format, but I don;t
>> > think you are doing anybody a favour here.  Can we not rather use
>> > _exactly_ the same text format as U-Boot uses with it's import /
>> > export commands?
>>
>> That would be nice, but how to we handle newlines? Some scripts are
>> quite long. Do we need to put \ at the end of every line? That feels a
>> bit painful to me.
>
> 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?

>
>> Also how do we handle #define? Without it I don't think this feature
>> is useful, since the existing build system often sticks CONFIG
>> variables into the environment.
>
> 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.

>
>> I believe that is already possible - you should be able to take the
>> output of 'env export -t' and put it in the .env file. I have not
>> tried it though.
>
> Hm... I really think we should agree on a common format her e- one
> that is easy to work with on both sides.

Agreed.

>
>> > Example (using notation as exported by U-Boot using "env export -t"):
>> >
>> >         foo=setenv xxx\
>> >         one=1;setenv yyy\
>> >         two=2;setenv zzz\
>> >         three=3
>> >
>> >> +     # Print out all the variables
>> >> +     for (var in vars) {
>> >> +             print var "=" vars[var] "\\0";
>> >> +     }
>> >
>> > I think it should not be difficult to find examples that would result
>> > incorrect output.
>>
>> I will take a look at this - here it is the \ at the end of line which
>> needs to be handled.
>
> 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?

>
>> > I guess this needs more work - but then - why define a new format at
>> > all?  Why not use what U-Boot uses itself?
>>
>> See above, would be good to resolve this issue before going any further.
>
> "Above" I cannot see any explanation why you define a new format
> except for the fact that the backslash as marker for continuation
> lines is "painful".   I'm open on discussing a new format for text
> representation (which then also should be used by "env print" and "env
> export -t" ?).  But I'd like to see a description of that format
> first (and not just a few examples I can guess from).