[U-Boot] RFQ: Makefile cleanup

[Wolfgang Denk]

Dear Scott Wood,

In message <20101006154256.20239b92 at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All I ask is a chance to prove that money can't make me happy.