From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Wed, 06 Oct 2010 22:16:43 +0200 Subject: [U-Boot] RFQ: Makefile cleanup In-Reply-To: <20101006195427.E4EFC1539A0@gemini.denx.de> References: <20101006195427.E4EFC1539A0@gemini.denx.de> Message-ID: <4CACD92B.5070300@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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...]][:[,]] 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.