On Tue, Feb 09, 2016 at 10:53:48AM -0700, Stephen Warren wrote: > 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 <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? > > > >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.
Right. Can't we just make it another string Kconfig like LOCALVERSION, not need to pass -D.... and then it's set via poking the config file by CI, etc? -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
