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? -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
