[U-Boot] [PATCH v8 05/13] kconfig: switch to Kconfig

[Stephen Warren <swarren@wwwdotorg.org>]

On 07/31/2014 02:34 PM, Tom Rini wrote:
> On Wed, Jul 30, 2014 at 08:08:02PM -0600, Stephen Warren wrote:
>> On 07/30/2014 07:56 PM, Masahiro Yamada wrote:
>>> Hi Stephen,
>>>
>>>
>>> On Wed, 30 Jul 2014 17:05:21 -0600
>>> Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>
>>>> On 07/29/2014 11:08 PM, Masahiro Yamada wrote:
>>>>> This commit enables Kconfig.
>>>>> Going forward, we use Kconfig for the board configuration.
>>>>> mkconfig will never be used. Nor will include/config.mk be generated.
>>>>>
>>>>> Kconfig must be adjusted for U-Boot because our situation is
>>>>> a little more complicated than Linux Kernel.
>>>>> We have to generate multiple boot images (Normal, SPL, TPL)
>>>>> from one source tree.
>>>>> Each image needs its own configuration input.
>>>>>
>>>>> Usage:
>>>>>
>>>>> Run "make <board>_defconfig" to do the board configuration.
>>>>
>>>> This is quite unfortunate; it breaks any scripts that were building U-Boot via "make <board>_config; make". Can't we add another rule to allow the old build commands to work?
>>>
>>>
>>> Technically, yes. I think we can.
>>>
>>> But I do not like having it permanently.
>>>
>>>
>>> So, we support both *_defconfig and *_config for a while (maybe 6 months or so?)
>>> and then remove *_config.
>>>
>>> Deal?
>>
>> If the old command-line is ever going to be removed, there's no point
>> supporting both at all; I'd have to hack my scripts to support both
>> sometime, so I may as well do it now rather than wait.
>>
>>>> Otherwise, I guess I'll have to hack my scripts to check whether e.g. scripts/multiconfig.py (which was added in this commit) is present in the tree, and execute different build commands based on that...
>>>
>>>
>>> Do you mean, you need to build some different versions of U-boot ?
>>
>> Yes. I own some scripts that build U-Boot, and they need to work on any
>> reasonable version of U-Boot that anyone might want to build. For
>> example, they build 2014.07 just fine, and there's no reason they should
>> ever stop being able to do that. I obviously also want my scripts to be
>> able to build any future version of U-Boot.
>
> So long as we have MAKEALL (and we'll have the discussion about moving
> to buildman sometime soon) this just becomes:
> if [ -x tools/genboardscfg.py ]; then
>     tools/genboardscfg.py
> fi
>
> MAKEALL machine-name

There's now a large disadvantage to MAKEALL; it takes longer to run that 
to build U-Boot itself, since it must auto-generate boards.cfg. Perhaps 
that's only done once, or when the data changes.

Also, is MAKEALL an/the official way to build U-Boot, or just a useful 
tool? I have the impression that running "make" is the official way to 
build U-Boot, but MAKEALL/buildman are useful wrapper tools if you want 
to do batch builds etc.