On Wed, 6 Oct 2010 22:16:43 +0200 Albert ARIBAUD albert.aribaud@free.fr wrote:
I accept the prefix, and generate a definition for CONFIG_SYS_TEXT_BASE. In the config.mk file, I replace the "sinclude ... config.tmp" by something like this:
ifdef CONFIG_SYS_TEXT_BASE TEXT_BASE = $(CONFIG_SYS_TEXT_BASE) endif
pro: The lines in boards.cfg don't get too long.
con: I have to adapt a number or board specific config.mk files (but I have to do this anyway to remove the then obsolete "sinclude" lines.
At the moment my preference goes with 2), but I would like to hear if this approach seems acceptable to others as well.
How about having the board's config.mk do something like:
ifdef CONFIG_NAND_SPL TEXT_BASE = ... endif
?
Humble proposal: admit an options field of the form
boardname[:[cfgopt1[,cfgopt2...]][:<opt1>[,<opt2>]]
I.e., have two sets of definitions, cfgopts and opts, separated by colons; each cfgopt or opt is of the form SYM or SYM=VAL. The cfgopt set gets the CONFIG_ prefix, the opt set does not.
Well, that addresses the line length argument, at the cost of complexity and syntax obscurity. But I changing TEXT_BASE to CONFIG_SYS_TEXT_BASE is something we probably want to do anyway. If we ever switch to kconfig, and we want the text base to be part of that, it will have to start with CONFIG_.
Even if we don't change TEXT_BASE now, we don't want to encourage people to add any new symbols in the second category. If we do add some hack to the boards.cfg syntax for this, IMHO it ought to be just for TEXT_BASE and not a generalized symbol setter.
Are we dropping the MK_ that mkconfig currently adds, BTW? Some examples in the introductory text use it and some don't.
-Scott