From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 9 Feb 2016 10:26:14 -0700 Subject: [U-Boot] [PATCH] Makefile: remove BUILD_TAG from KBUILD_CFLAGS In-Reply-To: <20160209170130.GL11375@bill-the-cat> References: <1454981534-15925-1-git-send-email-swarren@wwwdotorg.org> <56BA0FA3.6070503@gmail.com> <20160209170130.GL11375@bill-the-cat> Message-ID: <56BA2136.4070306@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>> >>> 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.