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

[Tom Rini]

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

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.

> 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.

Good point.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160209/d55b9544/attachment.sig>