Dear Graeme Russ,
In message AANLkTin-b-yyRaWhUBYLosoDO7RvuK7Hs=FttRBYxoxk@mail.gmail.com you wrote:
I feel that boards.cfg defines configurations, and therfore each additional field is, by definition, a configuration option and should be prefixed with CONFIG_
Good point, thanks.
I actually got really confused with TEXT_BASE and thought it was some kind of standard environment variable that ld magically used - it wasn't until I spent a day trolling through the makfile et al that I finally figurfed out that the linker script was 'made' and TEXT_BASE was just another define and I could add more to the parsing of the ld script. Having it as CONFIG_TEXT_BASE or CONFIG_SYS_TEXT_BASE would have alerted me straight up
Yes, I agree. Renaming TEXT_BASE into CONFIG_SYS_TEXT_BASE is probably the best solution here.
A couple of other questions:
- How do you un-define a CONFIG option via boards.cfg?
We don't. We cannot. The auto-generated config.h is included before the board config iule (which is necessary so the config options in the former can influence processing of the latter), but that means that any #undef in config.h will simply be overridden by a following #define in the board config file.
We don't need #undef so far, and we should try never to need it. Use additive logic instead, #define'ing only what you really (and always) need, and add configurable options (and this only when really needed).
- What happens when you try to re-define an option already in the board configuration file?
You get an error. For the same reasons. Don't do that.
Each board could have a main config with all the common configuration values and a number of secondary includes (which include the primary) for each specific configuration. The entry in boards.cfg would select a specific config_xxx.h file
That would be an option as well, but it would add a lot of tiny files, and not bring us any closer to a Kconfig based system.
Best regards,
Wolfgang Denk