Hi Wolfgang,
On Mon, Oct 28, 2013 at 3:16 PM, Wolfgang Denk <w...@denx.de> wrote:
> Dear Simon,
>
> In message <CAPnjgZ0+35Zd6_o=G0=
g-yl_mr-gitw+meyqk7bsxu_nvkv...@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).
>From my commit message:
At present U-Boot environment variables, and thus scripts, are defined
> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> to this file and dealing with quoting and newlines is harder than it
> should be. It would be better if we could just type the script into a
> text file and have it included by U-Boot.
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.
I agree creating a new format is not ideal - it's just that the existing C
header format is so painful...
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
