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 <swar...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
