[U-Boot] RFQ: Makefile cleanup

[Albert ARIBAUD <albert.aribaud@free.fr>]

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  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

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,
-- 
Albert.