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

[Jeroen Hofstee <dasuboot@myspectrum.nl>]

On 31-07-14 22:55, Stephen Warren wrote:
> 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.
>

there is, it is _terribly_ slow when dealing with warnings in the build. 
MAKEALL is much
better for that. Replacing the _config rule with _defconfig is just a 
bad idea afaic.

Regards,
Jeroen