OTOH options like CFG_LONGHELP may have to do with hardware - for example, if there is a hardware restriction in the maximum size of PPCBoot (like my often quoted 128 kB EPROM device)
simple enought:
config LONGHELP bool "Include long help texts" default n if ARCH_VERYSMALLBOARD help This add approx XX kB to U-Boot, so please be sure that the resulting binary still fit's into your EEPROM or FLASH.
But then, when you check just 20 randomly chosen board config files, you will find such a wide range of private extensions, which are strictly "local" (i. e. of interest only for that specific board), that I think it would be extremely difficult to maintain this under lkc.
No, not really.
Currently I have one bigger u-boot/config.in file, defining all the basic stuff. This one include u-boot/boards/config.in which in turn can include any board-specific u-boot/boards/<someboard>/config.in file --- or not.
So it is absolutely no problem to have in u-boot/boards/<someboard>/config.in an entry like
config IDP_PXA_STRANGE_FEATURE depend ARCH_IDP_PXA int "Strangeness of this feature" default 5
and in boards/idppxa/idppxa.c you can then simply have
#ifdef CONFIG_IDP_PXA_STRANGE_FEATURE printf("My strangeness is %d\n", CONFIG_IDPPXA_STRANGE_FEATURE); #endif
In this case it is quite clear that this feature is only for this one board. When you do "make xconfig" or "make menuconfig" and you select another board, you would not even see that this feature exists (because of the depend line).
And combining a lkc created config file with a second, board private config file, seems contraproductivee to me.
Not for me. Look at the kernel or at OpenZaurus. Both of this systems are build around lot's of config.in files in various directories. It's much easier to maintain and understand this way.