summaryrefslogtreecommitdiff
path: root/lib/lru_cache.c
diff options
context:
space:
mode:
authorMatthias Maennich <maennich@google.com>2021-06-12 17:18:38 +0300
committerMasahiro Yamada <masahiroy@kernel.org>2021-06-17 04:01:12 +0300
commita979522a1a88556e42a22ce61bccc58e304cb361 (patch)
treeb614804f871ab8b5cbbd5e1eed311bcc347f2b77 /lib/lru_cache.c
parent4a6795933a890d41504c6df04527d1e093a4cbe6 (diff)
downloadlinux-a979522a1a88556e42a22ce61bccc58e304cb361.tar.xz
kbuild: mkcompile_h: consider timestamp if KBUILD_BUILD_TIMESTAMP is set
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 Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Diffstat (limited to 'lib/lru_cache.c')
0 files changed, 0 insertions, 0 deletions