[PATCH]modify "make menuconfig" output

[Patrick Georgi]

In the mainboard selection, the selected mainboard is printed twice in
certain cases, this patch eliminates the second mention.

This change might have unintended side-effects, but seems to work okay

Signed-off-by: Patrick Georgi

[Myles Watson]

On Tue, Aug 25, 2009 at 10:56 AM, Patrick Georgi wrote:
> In the mainboard selection, the selected mainboard is printed twice in
> certain cases, this patch eliminates the second mention.
>
> This change might have unintended side-effects, but seems to work okay

I'd rather fix the offending boards.  Isn't it board-specific?  Maybe
I haven't seen all the cases.

Myles

[Patrick Georgi]

Am Dienstag, den 25.08.2009, 11:10 -0600 schrieb Myles Watson:
> On Tue, Aug 25, 2009 at 10:56 AM, Patrick Georgi wrote:
> > In the mainboard selection, the selected mainboard is printed twice in
> > certain cases, this patch eliminates the second mention.
> >
> > This change might have unintended side-effects, but seems to work okay
>
> I'd rather fix the offending boards.  Isn't it board-specific?  Maybe
> I haven't seen all the cases.

No, it's specific to the Kconfig source layout:

choice
config { THE BOARDS }
config { THE BOARDS' DEPENDENCIES }
endchoice

To fix that, we'd have to do
choice
config { THE BOARDS }
endchoice
config { THE BOARDS' DEPENDENCIES }

which doesn't work with the source statement

Patrick

[Myles Watson]

On Tue, Aug 25, 2009 at 11:37 AM, Patrick Georgi wrote:
> Am Dienstag, den 25.08.2009, 11:10 -0600 schrieb Myles Watson:
> > On Tue, Aug 25, 2009 at 10:56 AM, Patrick Georgi wrote:
> > > In the mainboard selection, the selected mainboard is printed twice in
> > > certain cases, this patch eliminates the second mention.
> > >
> > > This change might have unintended side-effects, but seems to work okay
> >
> > I'd rather fix the offending boards.  Isn't it board-specific?  Maybe
> > I haven't seen all the cases.
>
> No, it's specific to the Kconfig source layout:
>
> choice
> config { THE BOARDS }
> config { THE BOARDS' DEPENDENCIES }
> endchoice
>
> To fix that, we'd have to do
> choice
> config { THE BOARDS }
> endchoice
> config { THE BOARDS' DEPENDENCIES }
>
> which doesn't work with the source statement

How about this fix?

Signed-off-by: Myles Watson

Thanks,
Myles

[Patrick Georgi]

Am Dienstag, den 25.08.2009, 14:13 -0600 schrieb Myles Watson:
> How about this fix?

I thought about that, but it has the disadvantage that it spreads the
configuration of the board across two files.

I'm not sure what the best fix is...

Patrick

[Myles Watson]

On Tue, Aug 25, 2009 at 2:30 PM, Patrick Georgi wrote:
> Am Dienstag, den 25.08.2009, 14:13 -0600 schrieb Myles Watson:
> > How about this fix?
>
> I thought about that, but it has the disadvantage that it spreads the
> configuration of the board across two files.

Yes.

I'd like to think that much of the second file will disappear as
CONFIG_USE_DCACHE_RAM and others are moved to their final resting
places.  Then it might make sense to move the last few things like the
mainboard strings into the mainboard/<vendor>/Kconfig file.
> I'm not sure what the best fix is...

I guess the third option is live with it being printed twice.

Thanks,
Myles

[Uwe Hermann]

On Tue, Aug 25, 2009 at 02:34:22PM -0600, Myles Watson wrote:
> On Tue, Aug 25, 2009 at 2:30 PM, Patrick Georgi wrote:
> > Am Dienstag, den 25.08.2009, 14:13 -0600 schrieb Myles Watson:
> > > How about this fix?
> >
> > I thought about that, but it has the disadvantage that it spreads the
> > configuration of the board across two files.
>
> Yes.

Indeed, and I think we should avoid that. The small proposed patch
is perfectly fine, IMHO.

Acked-by: Uwe Hermann
> I'd like to think that much of the second file will disappear as
> CONFIG_USE_DCACHE_RAM and others are moved to their final resting
> places.  Then it might make sense to move the last few things like the
> mainboard strings into the mainboard/<vendor>/Kconfig file.

I doubt this will always work, there are many per-board options that
will still be required, and they should really be in the board dir, IMHO.
> > I'm not sure what the best fix is...
>
> I guess the third option is live with it being printed twice.

Nah, why should we? The fix is easy.

Uwe.

[Myles Watson]

> Nah, why should we? The fix is easy.

The point of Kconfig is that it is standard.  We had a custom config
tool already.

Thanks,
Myles

[Uwe Hermann]

On Wed, Aug 26, 2009 at 09:07:22AM -0600, Myles Watson wrote:
> > Nah, why should we? The fix is easy.
>
> The point of Kconfig is that it is standard.  We had a custom config
> tool already.

Sure, I agree, but this small fix doesn't significantly change the
tool's usage in any way. Besides we already have small changes
against upstream's kconfig to adapt it to our needs anyway.

Uwe.