[U-Boot] [PATCH] Clean all defconfigs with savedefconfig

[Joe Hershberger]

Hi Stephen,

On Mon, May 11, 2015 at 4:07 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 05/11/2015 02:17 PM, Joe Hershberger wrote:
>>
>> Hi Stephen,
>>
>> On Mon, May 11, 2015 at 3:02 PM, Stephen Warren <swarren at wwwdotorg.org>
>> wrote:
>>>
>>> On 05/11/2015 11:08 AM, Joe Hershberger wrote:
>>>>
>>>>
>>>> In order to reduce merge conflicts and to maintain the simplest possible
>>>> defconfig files, we should be using the savedefconfig feature of Kconfig
>>>> every time a new feature is added. This keeps the defconfig settings to
>>>> a minimum (only those things not default) and keeps them in the same
>>>> order as the Kconfig options.
>>>
>>>
>>>
>>>> diff --git a/configs/jetson-tk1_defconfig b/configs/jetson-tk1_defconfig
>>>
>>>
>>>
>>>> -CONFIG_TARGET_JETSON_TK1=y
>>>
>>>
>>>
>>> Doesn't that (and the equivalent change in other files such as
>>> harmony_defconfig) break the build, since the Kconfig option that selects
>>> the particular board is no longer selected?
>>
>>
>> That's a bit of a peculiar case caused by the fact that Kconfig sees
>> that board as the default board, so it removes the explicit setting.
>>
>> The only problem I see with that is if a new board is added to the top
>> of the list. We can maybe fix this by changing all of the menus of
>> boards to optional, but I'm not sure that's what we want either.
>
>
> I certainly think we want to make the defconfig files not change semantics
> if someone adds a new board earlier in the list, or otherwise changes the
> sort order.
>
> Right now, the defconfig files do this by explicitly containing an entry for
> the board to build for, even if it's the default in Kconfig. that's at least
> simple, but interacts badly with savedefconfig.
>
> Perhaps we can modify e.g. arch/arm/mach-tegra/tegra124/Kconfig (and all
> other Kconfig files with choices like this, i.e. choices that are more than
> simply a different value that's selected but rather change the whole meaning
> of the build target) to explicitly set the default. That way, if the order
> of choice entries changes, the defconfig won't change meaning. For example:
>
> choice
>         prompt "Tegra124 board select"
>         # Do not change this value without editing the defconfig for the
>         # board that the current default. You'd need to add e.g.:
>         # CONFIG_TARGET_JETSON_TK1=y to that file.
>         default TARGET_JETSON_TK1

I think that's a viable solution. I still want to play with the
possibility of using the 'optional' key word for the choice because I
think it might get it to behave the way people assume it works. This
certainly is a way to deal with the accidental change in value of a
defconfig.

I'll let you know what I find and regenerate if it works out.

Cheers,
-Joe