linux-kbuild.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masahiro Yamada <masahiroy@kernel.org>
To: Matthias Maennich <maennich@google.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Cc: Android Kernel" <kernel-team@android.com>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH] kbuild: mkcompile_h: consider timestamp if KBUILD_BUILD_TIMESTAMP is set
Date: Thu, 17 Jun 2021 10:05:26 +0900	[thread overview]
Message-ID: <CAK7LNAQkoqTG540EOER27G83z+DO5fkeHi-in-vRYkrbX-o0cg@mail.gmail.com> (raw)
In-Reply-To: <20210612141838.1073085-1-maennich@google.com>

On Sat, Jun 12, 2021 at 11:18 PM Matthias Maennich <maennich@google.com> wrote:
>
> To avoid unnecessary recompilations, mkcompile_h does not regenerate
> compile.h if just the timestamp changed.
> Though, if KBUILD_BUILD_TIMESTAMP is set, an explicit timestamp for the
> build was requested, in which case we should not ignore it.
>
> If a user follows the documentation for reproducible builds [1] and
> defines KBUILD_BUILD_TIMESTAMP as the git commit timestamp, a clean
> build will have the correct timestamp. A subsequent cherry-pick (or
> amend) changes the commit timestamp and if an incremental build is done
> with a different KBUILD_BUILD_TIMESTAMP now, that new value is not taken
> into consideration. But it should for reproducibility.
>
> Hence, whenever KBUILD_BUILD_TIMESTAMP is explicitly set, do not ignore
> UTS_VERSION when making a decision about whether the regenerated version
> of compile.h should be moved into place.
>
> [1] https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html
>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: linux-kbuild@vger.kernel.org
> Signed-off-by: Matthias Maennich <maennich@google.com>
> ---


Applied to linux-kbuild. Thanks.


>  scripts/mkcompile_h | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/mkcompile_h b/scripts/mkcompile_h
> index 4ae735039daf..a72b154de7b0 100755
> --- a/scripts/mkcompile_h
> +++ b/scripts/mkcompile_h
> @@ -70,15 +70,23 @@ UTS_VERSION="$(echo $UTS_VERSION $CONFIG_FLAGS $TIMESTAMP | cut -b -$UTS_LEN)"
>  # Only replace the real compile.h if the new one is different,
>  # in order to preserve the timestamp and avoid unnecessary
>  # recompilations.
> -# We don't consider the file changed if only the date/time changed.
> +# We don't consider the file changed if only the date/time changed,
> +# unless KBUILD_BUILD_TIMESTAMP was explicitly set (e.g. for
> +# reproducible builds with that value referring to a commit timestamp).
>  # A kernel config change will increase the generation number, thus
>  # causing compile.h to be updated (including date/time) due to the
>  # changed comment in the
>  # first line.
>
> +if [ -z "$KBUILD_BUILD_TIMESTAMP" ]; then
> +   IGNORE_PATTERN="UTS_VERSION"
> +else
> +   IGNORE_PATTERN="NOT_A_PATTERN_TO_BE_MATCHED"
> +fi
> +
>  if [ -r $TARGET ] && \
> -      grep -v 'UTS_VERSION' $TARGET > .tmpver.1 && \
> -      grep -v 'UTS_VERSION' .tmpcompile > .tmpver.2 && \
> +      grep -v $IGNORE_PATTERN $TARGET > .tmpver.1 && \
> +      grep -v $IGNORE_PATTERN .tmpcompile > .tmpver.2 && \
>        cmp -s .tmpver.1 .tmpver.2; then
>     rm -f .tmpcompile
>  else
> --
> 2.32.0.272.g935e593368-goog
>


-- 
Best Regards
Masahiro Yamada

  reply	other threads:[~2021-06-17  1:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-12 14:18 [PATCH] kbuild: mkcompile_h: consider timestamp if KBUILD_BUILD_TIMESTAMP is set Matthias Maennich
2021-06-17  1:05 ` Masahiro Yamada [this message]
2021-06-17  1:43   ` Masahiro Yamada
2021-06-17  9:18     ` Matthias Maennich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK7LNAQkoqTG540EOER27G83z+DO5fkeHi-in-vRYkrbX-o0cg@mail.gmail.com \
    --to=masahiroy@kernel.org \
    --cc=kernel-team@android.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maennich@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).