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

Wolfgang Denk wd at denx.de
Mon Oct 28 22:16:53 CET 2013


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).

> 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?

> 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.

> > 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.

> > 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).

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
Only two things are infinite,  the universe and human stupidity,  and
I'm not sure about the former.                     -- Albert Einstein


More information about the U-Boot mailing list