[U-Boot] [PATCH] Makefile: remove BUILD_TAG from KBUILD_CFLAGS

[Stephen Warren]

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 at 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?

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.

I could easily hack my Jenkins build scripts to unset that variable, but 
I do like the test logs showing the Jenkins build ID so I can validate 
the correct binary actually ran. So I'd rather not simply remove the tag 
from the message.