[U-Boot] 答复: [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets

[Hu Mingkai-B21284]

Hi All,
 
About this question, now we have two interim methods until we have kconfig:
 
1. As talked about with Wolfgang yesterday, just pass the board config name
to config.h, then leave the board config file to handle the different targets.
 
The patch can find through this link:
http://lists.denx.de/pipermail/u-boot/2009-September/060173.html
 
 
2. Add a '-t'option in mkconfig to split board config name to individual targets,
then put them to board config file.
 
I modified the patch over version 1 and sent it again:
http://lists.denx.de/pipermail/u-boot/2009-September/060268.html
 
Maybe the option 1 is a little clear than option 2, after all it just produces
one uncontrolled macro, but it'll make the board config file lengthy when there
are more orthogonal options as Scott pointed it. 
 
For me these two options both work - 8536 just have two orthognal options at most now :-)
For anyone else, I don't know, it looks like anyone else doesn't care about this issue.
 
Wolfgang, I think it'll be hlep to pick up one of these for multiple board config targets,
or else we have to go back to 'findstring' method on the top makefile. How do you think about it?
 
BTW, when can we get kconfig in U-Boot? :-)
 
Mang thanks,
Mingkai

________________________________

From: Wood Scott-B07421
Sent: 2009-9-9 (星期三) 4:58
To: Wolfgang Denk
Cc: Hu Mingkai-B21284; Kumar Gala; U-Boot-Users ML; Mike Frysinger
Subject: Re: [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets



Wolfgang Denk wrote:
>> Would this still be a big problem if the auto-generated defines were put
>> in their own namespace (such as the CONFIG_MK_* that you suggested)?
>
> Probably not a big problem, and maybe not even a practical problem.
> But it is still ugly, and nothing I really like.

Well, yes -- the long term, less-ugly solution is kconfig.

> But as it seems that nobody else cares about this, and I don;t have
> any better ideas either, I guess I should not block this.

Thanks.

-Scott