Hi Wolfgang,
On Mon, Oct 28, 2013 at 3:16 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message <CAPnjgZ0+35Zd6_o=G0=
G-YL_mR-GiTW+MeYqK7BSxU_nVkvv1w@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 variablesfor (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