[U-Boot] [PATCH] Makefile: remove BUILD_TAG from KBUILD_CFLAGSilver pepper blue dog

[Stephen Warren <swarren@wwwdotorg.org>]

On 02/09/2016 10:43 AM, Tom Rini wrote:
> On Tue, Feb 09, 2016 at 10:26:14AM -0700, Stephen Warren wrote:
>> On 02/09/2016 10:01 AM, Tom Rini wrote:
>>> On Tue, Feb 09, 2016 at 08:11:15AM -0800, James Chargin wrote:
>>>>
>>>>
>>>> On 02/08/2016 05:32 PM, Stephen Warren wrote:
>>>>> From: Stephen Warren <swarren@nvidia.com>
>>>>>
>>>>> If BUILD_TAG is part of KBUILD_CFLAGS, then any time the value changes,
>>>>> all files get rebuilt. In a continuous integration environment, the value
>>>>> will change every build. This wastes time assuming that incremental
>>>>> builds would otherwise occur.
>>>>>
>>>>> To solve this, remove BUILD_TAG from KBUILD_FLAGS and add it to the end of
>>>>> "local version".
>>>>>
>>>>> This has other advantages too:
>>>>> - The special case for BUILD_TAG in display_options.c can be removed.
>>>>> - The version printed by the "version" command exactly matches what is
>>>>>    printed at boot.
>>>>>
>>>>> Old sign-on message:
>>>>> U-Boot 2016.03-rc1-00044-g4085db5e767b (Feb ...), Build: bar-bas
>>>>>
>>>>> New sign-on message:
>>>>> U-Boot 2016.03-rc1-00044-g4085db5e767b-bar-baz (Feb ...)
>>>>
>>>> I would urge this not be done. The display of the BUILD_TAG on
>>>> startup is pretty useful in my environment. It's been there for a
>>>> long time and some of my users have grown used to it.
>>>>
>>>> Of all the parts of the sign-on message, I'd rather the git hash go
>>>> away than the BUILD_TAG. None of my users really care about the
>>>> level of detail of the git hash and won't spend the time required to
>>>> use this hash to determine if they have the version they want. (Some
>>>> don't have a repo clone, and don't care to, and so can't easily make
>>>> the correspondence even if they wanted to).
>>>
>>> Yeah, I think this is too widely used of a thing to change.  FWIW, I
>>> really like githashes since it means you can see if $random-binary is
>>> something you have in $vendor-tree or not.  So I think in this case, NAK
>>> on the patch and maybe need to poke Travis-CI on how to or not to tag
>>> things?
>>
>> Do you mean you think people currently rely upon the ", Build: xxx"
>> format in the sign-on message, and the "version" command /not/
>> printing that information?
>
> I mean that the places we construct strings like this are likely relied
> upon by people, yes.
>
>> If so, I'll go back to trying to work out how to get Kbuild to
>> transfer the environment variable into a CONFIG_XXX option so that
>> modifying it only causes a rebuild of the one file that uses the
>> value.
>
> A quick peak and I think that:
> (a) LOCALVERSION needs a little love somewhere to ensure that it in fact
> does not exceed 64 characters (and pushing upstream to the kernel
> anything relevant here)
> (b) Yes, adjusting BUILD_TAG into CONFIG_BUILD_TAG is probably the best
> answer and probably not even that bad.  I don't think we need an
> automagic conversion, just noting it in the release emails and the
> sudden lack of Build: should get people that are using it to update
> their scripts.

Unfortunately, simply renaming the variable won't work; Kconfig/Kbuild 
need to know something about it in order to do their 
rebuild-only-on-change magic (and the value must be removed from CFLAGS 
too). I was having a hard time getting that to work, but I'll take 
another look.