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

[Joe Hershberger]

Hi Masahiro-san,

On Tue, May 12, 2015 at 8:24 PM, Masahiro Yamada
<yamada.masahiro at socionext.com> wrote:
> Hi.
>
> I was a little late...
>
> 2015-05-13 1:32 GMT+09:00 Tom Rini <trini at konsulko.com>:
>> On Tue, May 12, 2015 at 11:20:07AM -0500, Joe Hershberger wrote:
>>> Hi Tom,
>>>
>>> On Tue, May 12, 2015 at 10:18 AM, Tom Rini <trini at konsulko.com> wrote:
>>> > On Mon, May 11, 2015 at 01:32:40PM -0500, Joe Hershberger wrote:
>>> >> Hi Tom,
>>> >>
>>> >> On Mon, May 11, 2015 at 12:08 PM, Joe Hershberger
>>> >> <joe.hershberger at ni.com> 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.
>>> >> >
>>> >> > Signed-off-by: Joe Hershberger <joe.hershberger at ni.com>
>>> >> > Cc: Masahiro Yamada <yamada.masahiro at socionext.com>
>>> >>
>>> >> This is easy to generate, but as you can imagine it will become a
>>> >> conflict rapidly. Please let me know if you choose to wait past today
>>> >> on this... if you do, let me know when you want to pull it in and I
>>> >> can generate it again. We should coordinate.
>>> >
>>> > I'm taking what you and Stephen talked about as "changes will be coming"
>>> > and not applying this patch.
>>>
>>> That's correct. I'm running a test now. Are you about to push more
>>> changes that include defconfig or Kconfig changes or am I safe with
>>> the current HEAD to generate this patch?
>>
>> You're safe to continue.  Please cc Stephen on that one since I'll want
>> his ack before I grab it.  Thanks!
>>
>
>
> I don't want to bother you guys after Tom decided to apply this patch,
> but just my comment.
>
> I personally hesitate to make the board choice optional.
>
> With this change, Kconfig is allowed to generate the .config without any board.

While that's true, every defconfig will specify a board. A user would
have to either not select a defconfig or deselect the board after a
defconfig. Neither sounds plausible.

> The build always fails with such a .config,
> i.e. it is completely an insane .config.

Of course... it would also happen if you select a dummy board.

> I think Stephen's idea (adding the default board explicitly) works well.

While this is OK, it is lots of extra definition and lots of boards
who behave a little differently that all the other boards. I don't
care for it much, but if we decide to go away from the 'optional'
implementation, then this is the way I would hope someone would go.

> Another solution can be seen arch/arc/Kconfig.
> Alexey added TARGET_DUMMY to the top of the board select list.
> It looks a bit ugly, so I do not like it very much, though.

I dislike this the most. Extra definition and just as insane if a user
selects insane. I'll send a patch tomorrow to remove the TARGET_DUMMY
board (for consistency).

Cheers
-Joe