Dear Simon,
In message CAPnjgZ3WVvso8uSeKyiOg6oR_R=nkguGZYXGb9Ws-s5dmO5GmQ@mail.gmail.com you wrote:
- This requires that the .env files are run through CPP, which is only added in a later patch.
OK perhaps I should just merge the patches. It is a bit artificial having two and it seems that people agree we need the += syntax.
Yes, some way to append to the environment is useful, and using '+=' is an intuitive syntax for it. I'm just not happy about sneeking in a new, undocumented restriction on U-Boot variable names. Yes, there are probably not many systems around (if any) where a variable name ends in a plus sign, but we should be consistent.
I have to admit that I don't have any nice alternative suggestion. If we stick with the rule that only NUL and '=' cannot be used in a variable name, we could write
variable=+value
instead. But this does not look as nice as '+=', and we need an escape mechanism for the case where we want a simple assignment of a value that starts with a '+'.
BTW: If we would add such a feature to U-Boot (which seems to be no bad idea to me) we would probably implement an "env append" command?
- Even if I add an "#include board/<vendor>/env/common.env" in my <board>.env files, your logic would trigger on the existence of the common.env file and ignore the <board>.env files.
OK, so I if reverse that, are you happy? What do you think about my explanation above?
The longer I think about it the more I wonder if any hard coded file names are really a good way to handle this. For example there might be the case where we have 4 boards A, B, C and D, and boards A and B would use one env file, and C and D would use another. this does not match the "<board>.env" scheme, and "common.env" does not fit either, as we have two "common" files.
I wonder if there should rather be a Kconfig option so each board can select it's env file name; default would be "<board>.env". what do you think?
Best regards,
Wolfgang Denk