From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 410D3C4338F for ; Wed, 4 Aug 2021 22:14:44 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8E4CF61073 for ; Wed, 4 Aug 2021 22:14:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8E4CF61073 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 2A6D882BC7; Thu, 5 Aug 2021 00:14:41 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="Xye5/LYp"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D993D82C09; Thu, 5 Aug 2021 00:14:39 +0200 (CEST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id B50EA80C68 for ; Thu, 5 Aug 2021 00:14:35 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: by mail.kernel.org (Postfix) with ESMTPSA id 1B78560EE5; Wed, 4 Aug 2021 22:14:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628115272; bh=J1hQZnJnTtqBnxVHQNl+MRumvNkD5xdrBsU56TF87/c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xye5/LYpcXVgdBGt5UUzLqxhYDHGJeiA8K6kTpE+mWNSrP3xgzioe3oUuwyaf2TWn 6sUhpAvrlwH1GvZ4pCf6HzlltBDa6RvCwnYG+OrHVskjLP/AUoVUua7CdjNEpJ+fiC hmzYrm1Mqpw4qBS1YVi3kXjxYexJXrXFunJjHXXkj0yUzUxpSAZ/Mb4al6ohIQdUSb 8N2gs4teGECW2YaEWJwdQv/yA1nCnK3wjxHV3w0x+Ene7jx46DdxMakao+zdxe4BO3 6+MFswfAHlh+dJo86vP7HtrDSA/4exwjzK2dDMwcizac3gPoAIOZBl+SntZhcAQKPK kOiV4izR974Og== Received: by pali.im (Postfix) id E376A77F; Thu, 5 Aug 2021 00:14:29 +0200 (CEST) Date: Thu, 5 Aug 2021 00:14:29 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Tom Rini Cc: Sean Anderson , Simon Glass , Heinrich Schuchardt , Alexander Graf , Huan Wang , Angelo Dureghello , Wolfgang Denk , Priyanka Jain , Christophe Leroy , Bin Meng , Marek =?utf-8?B?QmVow7pu?= , U-Boot Mailing List Subject: Re: [PATCH 11/11] Remove including timestamp.h in version.h Message-ID: <20210804221429.wzw23up3ahoswuyd@pali> References: <20210802131838.21097-1-pali@kernel.org> <20210802131838.21097-12-pali@kernel.org> <815b40e2-aa57-abfb-901f-979507a9e3b7@seco.com> <20210804220914.GA858@bill-the-cat> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210804220914.GA858@bill-the-cat> User-Agent: NeoMutt/20180716 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Wednesday 04 August 2021 18:09:14 Tom Rini wrote: > On Wed, Aug 04, 2021 at 05:43:41PM -0400, Sean Anderson wrote: > > > > > > On 8/2/21 3:21 PM, Simon Glass wrote: > > > Hi Pali, > > > > > > On Mon, 2 Aug 2021 at 07:20, Pali Rohár wrote: > > > > > > > > Header file version.h does not use anything from timestamp.h. Including of > > > > timestamp.h has side effect which cause recompiling object file at every > > > > make run because timestamp.h changes at every run. > > > > > > > > So remove timestamp.h from version.h and include timestamp.h in files > > > > which needs it. > > > > > > > > This change reduce recompilation time of final U-Boot binary when U-Boot > > > > source files were not changed as less source files needs to be recompiled. > > > > > > > > Signed-off-by: Pali Rohár > > > > --- > > > > arch/arm/mach-rockchip/tpl.c | 4 ++++ > > > > board/work-microwave/work_92105/work_92105_display.c | 1 + > > > > cmd/version.c | 1 + > > > > common/spl/spl.c | 4 ++++ > > > > drivers/rtc/emul_rtc.c | 2 +- > > > > include/version.h | 2 -- > > > > 6 files changed, 11 insertions(+), 3 deletions(-) > > > > > > Reviewed-by: Simon Glass > > > > > > I assume we do actually want to regenerate the timestamp when U-Boot > > > builds, even if nothing has changed. Is that right? > > > > I know this is the current behavior, but it would be nice if this was > > not the case. If one is building U-Boot as part of a larger project, one > > might want to have a makefile rule like > > > > u-boot/u-boot.bin: > > $(MAKE) -C u-boot $(@F) > > > > but u-boot/u-boot.bin will always be remade even if no changes have been > > done. This will cause make to remake all dependents of U-Boot as well > > (which can be rather time-consuming). > > > > At the moment, I just use U-Boot as an order-only dependency and remake > > it manually. But I would love it if U-Boot was only remade if > > dependencies had actually changed, since this would make it easier to > > integrate it with the rest of my build system. > > Note that with this series applied, if you made use of > SOURCE_DATE_EPOCH, nothing would be rebuilt. IIRC with SOURCE_DATE_EPOCH nothing would be rebuilt also without applying this my patch series. > That may or may not make > sense however, in your case. This series does get us closer to being > able to do what the linux kernel does as there's now just one place > rather than a bunch of places that are rebuilt. Just small correction. Even with this patch series there would not be just one place. There are still more places but this patch series reduce number of these places.