Dear Simon, In message <capnjgz3tgwrk2ytm59ekumaipd5kaq39mu9bityl0y6d0h2...@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:w...@denx.de">w...@denx.de</a>> > wrote:<br>>= ... Argh... can you please turn this off? 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: w...@denx.de I have never understood the female capacity to avoid a direct answer to any question. -- Spock, "This Side of Paradise", stardate 3417.3 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot