Dear Simon,
In message CAPnjgZ3tGwRK2ytm59EKUmAiPD5kAq39Mu9BityL0Y6d0H2C1w@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 <<a href=3D"mailto:wd@denx.de">wd@denx.de</a>> wrote:<br>>=
...
Argh... can you please turn this off?
Best regards,
Wolfgang Denk