[U-Boot] RFQ: Makefile cleanup
Hi,
I'm working on a few patches to get rid of the remaining scripting in the Makefile, i. e. to move the remaining board descriptions into board.cfg; this work makes use of Marek Vasut's patch to extend the mkconfig script so it can process an additional "options" field.
For example, a board entry could now look like this:
TQM8260_AB powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x
Read this as:
"make TQM8260_AB_config" will set up a build for the following board definition:
ARCH = powerpc CPU = mpc8260 BOARD = tqm8260 VENDOR = tqc
The options field can contain multiple options: a board configuration name, optionally followed by a colon (':') and a list of options, which are separated by comma (','). In case there's a simple option like 256M_U_BOOT, this expand to "#define CONFIG_MK_256M_U_BOOT 1" in config.h . In case there's an assignment, like "RAM=8192", it expands to "#define CONFIG_MK_RAM 8192" in config.h .
Example:
FOO:HAS_BAR,BAZ=64
means: - the name of the board config file is include/configs/FOO.h - the generated file include/config.h will contain these lines:
#define CONFIG_HAS_BAR 1 #define CONFIG_BAZ 64
In our example above, include/config.h will contain the following settings:
#define CONFIG_MPC8260 1 #define CONFIG_200MHz 1 #define CONFIG_L2_CACHE 1 #define CONFIG_BUSMODE_60x 1 #define CONFIG_BOARDDIR board/tqc/tqm8260
So far, so good.
With this I can convert a large number of boards from the Makefile to boards.cfg - but I still have a problem with those that not only add settings to include/config.h, but that also add custom settings to some config.mk file, typically to adjust the TEXT_BASE setting, for example like this:
Makefile:
... @echo "TEXT_BASE = 0x01000000" > $(obj)board/amcc/acadia/config.tmp @echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk ...
board/amcc/acadia/config.mk:
... sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp ... ifndef TEXT_BASE TEXT_BASE = 0xFFF80000 endif ... ifdef CONFIG_NAND_U_BOOT ...
The settings in include/config.h are visible in the Makefiles through the automatically generated include/autoconf.mk; however, with the mechanism above I cannot generate a "TEXT_BASE" setting as currently all options automatically get prefixed with "CONFIG_".
Now I see two approaches for a solution:
1) I stop prefixing options with "CONFIG_" and write the full variable names instead.
pro: I have full controll over which definitions I generate, and I can handle it at a single, central location.
con: The lines in boards.cfg, which often are more than long enough, will become even longer. Our example above would now become:
TQM8260_AB powerpc mpc8260 tqm8260 tqc - TQM8260:CONFIG_MPC8260,CONFIG_200MHz,CONFIG_L2_CACHE,CONFIG_BUSMODE_60x
2) 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.
Or eventually somebody has a really clever idea how to tackle this...
Thanks in advance.
Best regards,
Wolfgang Denk
Le 06/10/2010 21:54, Wolfgang Denk a écrit :
Hi,
I'm working on a few patches to get rid of the remaining scripting in the Makefile, i. e. to move the remaining board descriptions into board.cfg; this work makes use of Marek Vasut's patch to extend the mkconfig script so it can process an additional "options" field.
For example, a board entry could now look like this:
TQM8260_AB powerpc mpc8260 tqm8260 tqc - TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x
Read this as:
"make TQM8260_AB_config" will set up a build for the following board definition:
ARCH = powerpc CPU = mpc8260 BOARD = tqm8260 VENDOR = tqc
The options field can contain multiple options: a board configuration name, optionally followed by a colon (':') and a list of options, which are separated by comma (','). In case there's a simple option like 256M_U_BOOT, this expand to "#define CONFIG_MK_256M_U_BOOT 1" in config.h . In case there's an assignment, like "RAM=8192", it expands to "#define CONFIG_MK_RAM 8192" in config.h .
Example: FOO:HAS_BAR,BAZ=64 means: - the name of the board config file is include/configs/FOO.h - the generated file include/config.h will contain these lines: #define CONFIG_HAS_BAR 1 #define CONFIG_BAZ 64In our example above, include/config.h will contain the following settings:
#define CONFIG_MPC8260 1 #define CONFIG_200MHz 1 #define CONFIG_L2_CACHE 1 #define CONFIG_BUSMODE_60x 1 #define CONFIG_BOARDDIR board/tqc/tqm8260
So far, so good.
With this I can convert a large number of boards from the Makefile to boards.cfg - but I still have a problem with those that not only add settings to include/config.h, but that also add custom settings to some config.mk file, typically to adjust the TEXT_BASE setting, for example like this:
Makefile:
... @echo "TEXT_BASE = 0x01000000"> $(obj)board/amcc/acadia/config.tmp @echo "CONFIG_NAND_U_BOOT = y">> $(obj)include/config.mk ...
board/amcc/acadia/config.mk:
... sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp ... ifndef TEXT_BASE TEXT_BASE = 0xFFF80000 endif ... ifdef CONFIG_NAND_U_BOOT ...
The settings in include/config.h are visible in the Makefiles through the automatically generated include/autoconf.mk; however, with the mechanism above I cannot generate a "TEXT_BASE" setting as currently all options automatically get prefixed with "CONFIG_".
Now I see two approaches for a solution:
I stop prefixing options with "CONFIG_" and write the full variable names instead.
pro: I have full controll over which definitions I generate, and I can handle it at a single, central location.
con: The lines in boards.cfg, which often are more than long enough, will become even longer. Our example above would now become:
TQM8260_AB powerpc mpc8260 tqm8260 tqc - TQM8260:CONFIG_MPC8260,CONFIG_200MHz,CONFIG_L2_CACHE,CONFIG_BUSMODE_60x
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.
Or eventually somebody has a really clever idea how to tackle this...
Thanks in advance.
Best regards,
Wolfgang Denk
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.
Example:
TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x:TEXT_BASE=0xFF000000
Will generate
#define CONFIG_MPC8260 1 #define CONFIG_200MHz #define CONFIG_L2_CACHE 1 #define CONFIG_BUSMODE_60x 1 #define TEXT_BASE 0xFF000000
Pros: you keep fine control on what's generated; you keep not-too-long lines in boards.cfg; you don't need to touch anything in the current code.
Cons: complexified the parsing of the boards.cfg options field.
Note that in my proposal I suggest that an options field can still only contain cfgopts, so that existing lines in boards.cfg will keep their current semantics.
Amicalement,
Dear Albert ARIBAUD,
In message 4CACD92B.5070300@free.fr you wrote:
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.
Ah! Good idea. I like that. Let me sleep on that, but I guess that's what I'll do.
Thanks a lot!
Best regards,
Wolfgang Denk
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
Dear Scott Wood,
In message 20101006154256.20239b92@udp111988uds.am.freescale.net you wrote:
How about having the board's config.mk do something like:
ifdef CONFIG_NAND_SPL TEXT_BASE = ... endif
Assuming we want to go for Kconfig or similar, I would like to keep such logic out of the config.mk files (at least not add more than there already is).
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_.
Good point.
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.
Agreed.
Are we dropping the MK_ that mkconfig currently adds, BTW? Some examples in the introductory text use it and some don't.
Yes, these get dropped. All we want todo is provide a different way to set configuration options, and a separate name space adds more problems than benefits.
Best regards,
Wolfgang Denk
Dear Scott Wood,
In message 20101006154256.20239b92@udp111988uds.am.freescale.net you wrote:
How about having the board's config.mk do something like:
ifdef CONFIG_NAND_SPL TEXT_BASE = ... endif
This is what some boardss already do...
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_.
OK. I tried this, but I'm actually running into a catch-22 situation after moving the CONFIG_SYS_TEXT_BASE settings into boards.cfg: Some boards (especially such that support both booting from NOR or, alternatively, from NAND flash, or from RAM) contain only a default setting for CONFIG_SYS_TEXT_BASE in their board specific config.mk file. For example "board/amcc/sequoia/config.mk":
... ifndef CONFIG_SYS_TEXT_BASE CONFIG_SYS_TEXT_BASE = 0xFFF80000 endif ...
For the NAND-boot version, a different setting (0x01000000) is used for CONFIG_SYS_TEXT_BASE. Before include/autoconf.mk exists, the default setting is used, but then suddenly the value changes to the intended setting. This causes compiler warnings when generating include/autoconf.mk:
include/config.h:4:1: warning: "CONFIG_SYS_TEXT_BASE" redefined <command-line>: warning: this is the location of the previous definition
To avoid these, I tried stripping any "-DCONFIG_SYS_TEXT_BASE=" settings from the compiler options when building include/autoconf.mk and include/autoconf.mk.dep .
But then I noticed that some boards had build errors, or the builds differed otherwise from the previous version (some commands not included, etc.). This was when I learned that we actually need the correct TEXT_BASE definition on some boards to get correct setttings into include/autoconf.mk.
In other words, we have a problem because some config settings which are currently defined in board/.../config.mk take immediate effect and get included into the generation of include/autoconf.mk, while other settings (through include/configs/<name>.h) are kind of "second class" settings.
We could, of course try and get rid of all such config settigns in the config.mk files and move all the config logic into the include/configs/<name>.h files, but then this is another big set of changes, which I would like to avoid at this point. It's difficult enough to keep my current work split indo understandable and bisectable patches.
Any ideas?
Best regards,
Wolfgang Denk
Hi all
In message 20101010151418.C169F14F310@gemini.denx.de I wrote:
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_.
OK. I tried this, but I'm actually running into a catch-22 situation after moving the CONFIG_SYS_TEXT_BASE settings into boards.cfg: Some boards (especially such that support both booting from NOR or, alternatively, from NAND flash, or from RAM) contain only a default setting for CONFIG_SYS_TEXT_BASE in their board specific config.mk file. For example "board/amcc/sequoia/config.mk":
In case anybody what's to see this problem in action, I've pushed my current working tree into the "Makefile-cleanup" branch of the u-boot-testing repository, see
http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/Make...
Best regards,
Wolfgang Denk
On Sunday, October 10, 2010 11:46:38 Wolfgang Denk wrote:
In case anybody what's to see this problem in action, I've pushed my current working tree into the "Makefile-cleanup" branch of the u-boot-testing repository, see
http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/Mak efile-cleanup
what's with the u-boot-testing tree instead of a dedicated branch in u-boot ? -mike
Dear Mike Frysinger,
In message 201010101424.36981.vapier@gentoo.org you wrote:
http://git.denx.de/?p=3Du-boot/u-boot-testing.git;a=3Dshortlog;h=3Drefs/head...
what's with the u-boot-testing tree instead of a dedicated branch in u-boot ?
Um.. this stuff is still heavily in flow.
I hope these commits are stable now:
6360255 Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE 6836296 mkconfig: change CONFIG_MK_ prefix into plain CONFIG_ af726cf Build: Add "board options" column to boards.cfg
but at least the two topmost commits
65370be Makefile: move all Power Architecture boards into boars.cfg ccc23e9 Makefile: avoid CONFIG_SYS_TEXT_BASE redefinitions
are still highly experimental, incomplete and incorrect.
I didn't feel this to be stuff for a branch in the master repo yet.
Best regards,
Wolfgang Denk
On Sunday, October 10, 2010 15:10:03 Wolfgang Denk wrote:
Mike Frysinger wrote:
http://git.denx.de/?p=3Du-boot/u-boot-testing.git;a=3Dshortlog;h=3Drefs /heads/Makefile-cleanup
what's with the u-boot-testing tree instead of a dedicated branch in u-boot ?
Um.. this stuff is still heavily in flow.
diff dev methodologies i guess. if it's in a sep branch labeled "experimental", i dont see the harm in throwing anything in there, even if it blows up all boards. -mike
Dear Mike Frysinger,
In message 201010101557.18003.vapier@gentoo.org you wrote:
http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;hrefs /heads/Makefile-cleanup
what's with the u-boot-testing tree instead of a dedicated branch in u-boot ?
Um.. this stuff is still heavily in flow.
diff dev methodologies i guess. if it's in a sep branch labeled "experimental", i dont see the harm in throwing anything in there, even if it blows up all boards.
Well, that's what we use the -testing repository for.
Best regards,
Wolfgang Denk
On Thu, Oct 7, 2010 at 7:16 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Le 06/10/2010 21:54, Wolfgang Denk a écrit :
Hi,
I'm working on a few patches to get rid of the remaining scripting in the Makefile, i. e. to move the remaining board descriptions into board.cfg; this work makes use of Marek Vasut's patch to extend the mkconfig script so it can process an additional "options" field.
With this I can convert a large number of boards from the Makefile to boards.cfg - but I still have a problem with those that not only add settings to include/config.h, but that also add custom settings to some config.mk file, typically to adjust the TEXT_BASE setting, for example like this:
Makefile:
... @echo "TEXT_BASE = 0x01000000"> $(obj)board/amcc/acadia/config.tmp @echo "CONFIG_NAND_U_BOOT = y">> $(obj)include/config.mk ...board/amcc/acadia/config.mk:
... sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp ... ifndef TEXT_BASE TEXT_BASE = 0xFFF80000 endif ... ifdef CONFIG_NAND_U_BOOT ...The settings in include/config.h are visible in the Makefiles through the automatically generated include/autoconf.mk; however, with the mechanism above I cannot generate a "TEXT_BASE" setting as currently all options automatically get prefixed with "CONFIG_".
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.
Example:
TQM8260:MPC8260,200MHz,L2_CACHE,BUSMODE_60x:TEXT_BASE=0xFF000000Will generate
#define CONFIG_MPC8260 1 #define CONFIG_200MHz #define CONFIG_L2_CACHE 1 #define CONFIG_BUSMODE_60x 1 #define TEXT_BASE 0xFF000000
Pros: you keep fine control on what's generated; you keep not-too-long lines in boards.cfg; you don't need to touch anything in the current code.
Cons: complexified the parsing of the boards.cfg options field.
Note that in my proposal I suggest that an options field can still only contain cfgopts, so that existing lines in boards.cfg will keep their current semantics.
I feel that boards.cfg defines configurations, and therfore each additional field is, by definition, a configuration option and should be prefixed with CONFIG_
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
So I vote for #2
A couple of other questions: - How do you un-define a CONFIG option via boards.cfg? - What happens when you try to re-define an option already in the board configuration file?
P.S. Here's a thought I ended up discarding: 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
eg
boards.cfg: TQM8260 powerpc mpc8260 tqm8260 tqc - TQM8260_AB powerpc mpc8260 tqm8260 tqc -
/include/configs/TQM8260_AB.h:
#include "configs/TQM8260.h"
#define MPC8260 #define 200MHz #define L2_CACHE #define BUSMODE_60x
Dear Graeme Russ,
P.S. Here's a thought I ended up discarding: 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
eg
boards.cfg: TQM8260 powerpc mpc8260 tqm8260 tqc - TQM8260_AB powerpc mpc8260 tqm8260 tqc -
/include/configs/TQM8260_AB.h:
#include "configs/TQM8260.h"
#define MPC8260 #define 200MHz #define L2_CACHE #define BUSMODE_60x
That would make more sense to me. But it would even more crowd the include/configs directory. A while ago I had proposed to change over to: include/configs/<vendor>/<board>.h but that was rejected.
[Observation:] But if we really head for linux style *config we would need a <board>_defconfig individually for each variant... But I don't think we are there anytime soon. Many configs contain conditionals and *config does not handle long (multiline) strings nicely...
Best Regards, Reinhard
On 2010/10/07 2:46 AM, Reinhard Meyer wrote:
[Observation:] But if we really head for linux style *config we would need a <board>_defconfig individually for each variant... But I don't think we are there anytime soon. Many configs contain conditionals and *config does not handle long (multiline) strings nicely...
Best Regards, Reinhard
Keep in mind that the Linux folk are looking for an alternative to the defconfig mess that they have currently.
Linus has stated that he will delete all the ARM defconfigs soon.
Rogan
Dear Rogan Dawes,
In message 4CAD569E.3020706@dawes.za.net you wrote:
Keep in mind that the Linux folk are looking for an alternative to the defconfig mess that they have currently.
Linus has stated that he will delete all the ARM defconfigs soon.
I think the current Linux approach is focussed on generating single kernel images that can be used on as many as possible platforms. This is needed for things like building Linux distributions and such.
U-Boot, on the other hand, is very much bound to specific hardware configurations, and at least so far (*) we will always need secial configurations for each board. This makes a pretty much fundamental difference.
(*) We discussed before to auto-configure U-Boot for example based on a device tee description of the hardware. But it is still a long way to go.
Best regards,
Wolfgang Denk
On 2010/10/07 7:22 AM, Wolfgang Denk wrote:
Dear Rogan Dawes,
In message 4CAD569E.3020706@dawes.za.net you wrote:
Keep in mind that the Linux folk are looking for an alternative to the defconfig mess that they have currently.
Linus has stated that he will delete all the ARM defconfigs soon.
I think the current Linux approach is focussed on generating single kernel images that can be used on as many as possible platforms. This is needed for things like building Linux distributions and such.
U-Boot, on the other hand, is very much bound to specific hardware configurations, and at least so far (*) we will always need secial configurations for each board. This makes a pretty much fundamental difference.
(*) We discussed before to auto-configure U-Boot for example based on a device tee description of the hardware. But it is still a long way to go.
Best regards,
Wolfgang Denk
My understanding of it (although I have not followed it closely) was that they were looking for a mechanism to specify those things that should be in the configuration at a high level, that would then lead to the rest of the dependent items being selected automatically.
So, rather than having a *full* config file (and all the associated churn as individual settings are changed within the kernel), they would only have a snippet that selects the specific features for the board, that would then cascade-select the rest of the settings for a full kernel config.
That was considered acceptable, afaik.
Rogan
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
participants (7)
-
Albert ARIBAUD -
Graeme Russ -
Mike Frysinger -
Reinhard Meyer -
Rogan Dawes -
Scott Wood -
Wolfgang Denk