build: let CMake determine the year

fanquake commented at 9:25 am on May 8, 2025: member

Then we no-longer have to “bump” it.

See https://cmake.org/cmake/help/latest/command/string.html#timestamp.

Note:

If the SOURCE_DATE_EPOCH environment variable is set, its value will be used instead of the current time. See https://reproducible-builds.org/specs/source-date-epoch/ for details.

DrahtBot commented at 9:25 am on May 8, 2025: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32445.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	hebasto, laanwj, purpleKarrot, w0xlt
Concept NACK	maflcko

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

DrahtBot added the label Build system on May 8, 2025

laanwj commented at 9:36 am on May 8, 2025: member

(no longer relevant)

fanquake commented at 9:39 am on May 8, 2025: member

What about making the COPYRIGHT_YEAR depend on the last git commit date in UTC?

I’m open to implementing this in any way, but if the logic for doing so, is going to end up being more than a few lines / add other requirements (i.e what happens if you’re building from a tarball/no git etc), then maybe we shouldn’t bother. Just wanted to -1 the number of things that need maintenance.

fanquake marked this as a draft on May 8, 2025

in CMakeLists.txt:31 in f930f5e110 outdated

27@@ -28,7 +28,7 @@ set(CLIENT_VERSION_MINOR 99)
28 set(CLIENT_VERSION_BUILD 0)
29 set(CLIENT_VERSION_RC 0)
30 set(CLIENT_VERSION_IS_RELEASE "false")
31-set(COPYRIGHT_YEAR "2025")
32+string(TIMESTAMP COPYRIGHT_YEAR "%Y")

hebasto commented at 9:42 am on May 8, 2025:

nit: Add UTC option to avoid using local time?

fanquake commented at 10:55 am on May 8, 2025:

Added the UTC option.

hebasto approved

hebasto commented at 9:42 am on May 8, 2025: member

ACK f930f5e11024fd44a9f1c666d6eee3c9c19edfa0.

It would be useful to mention in the commit message / PR description a note from the CMake docs:

If the SOURCE_DATE_EPOCH environment variable is set, its value will be used instead of the current time.

laanwj commented at 9:47 am on May 8, 2025: member

If the SOURCE_DATE_EPOCH environment variable is set, its value will be used instead of the current time.

Well that’s some important context… Agree in that case.

build: let CMake determine the year

Then we no-longer have to "bump" it.

See https://cmake.org/cmake/help/latest/command/string.html#timestamp.

Note:

> If the SOURCE_DATE_EPOCH environment variable is set, its value
> will be used instead of the current time. See
> https://reproducible-builds.org/specs/source-date-epoch/ for details.

dfeac76b95

fanquake force-pushed on May 8, 2025

fanquake commented at 10:56 am on May 8, 2025: member

It would be useful to mention in the commit message / PR description a note from the CMake docs:

Added the relevant docs to the commit message.

fanquake marked this as ready for review on May 8, 2025

hebasto approved

hebasto commented at 12:19 pm on May 8, 2025: member

re-ACK dfeac76b951fc2d28e0832b176f3c8ad595697f1.

laanwj approved

laanwj commented at 12:36 pm on May 8, 2025: member

Code review ACK dfeac76b951fc2d28e0832b176f3c8ad595697f1

For example:

0$ export SOURCE_DATE_EPOCH=1
1$ cmake -B build
2$ grep YEAR build/src/*.h
3build/src/bitcoin-build-config.h:#define COPYRIGHT_YEAR 1970

In the guix build it sets SOURCE_DATE_EPOCH based on the last commit

0SOURCE_DATE_EPOCH="${SOURCE_DATE_EPOCH:-$(git -c log.showSignature=false log --format=%at -1)}"

So ostensibly this works out the correct date deterministically.

Should test an actual guix build to be sure.

purpleKarrot commented at 1:43 pm on May 8, 2025: contributor

When someone builds from a tarball that is more than a year old, this will use the current year instead of the year of the release. Is that a valid use case? Otherwise, ACK dfeac76b951fc2d28e0832b176f3c8ad595697f1.

laanwj commented at 3:15 pm on May 8, 2025: member

When someone builds from a tarball that is more than a year old, this will use the current year instead of the year of the release. Is that a valid use case?

Not only with tarballs, it’s true for any non-guix build, also from an old git commit.

in CMakeLists.txt:31 in dfeac76b95

27@@ -28,7 +28,7 @@ set(CLIENT_VERSION_MINOR 99)
28 set(CLIENT_VERSION_BUILD 0)
29 set(CLIENT_VERSION_RC 0)
30 set(CLIENT_VERSION_IS_RELEASE "false")
31-set(COPYRIGHT_YEAR "2025")
32+string(TIMESTAMP COPYRIGHT_YEAR "%Y" UTC)

ryanofsky commented at 3:24 pm on May 8, 2025:

In commit “build: let CMake determine the year” (dfeac76b951fc2d28e0832b176f3c8ad595697f1)

Doesn’t this make the build nondeterministic?

laanwj commented at 3:26 pm on May 8, 2025:

No; SOURCE_DATE_EPOCH, which is set by the guix build, is respected: #32445#pullrequestreview-2824986604

fanquake commented at 4:08 pm on May 8, 2025: member

Guix Build

 001f0af9244fe88c5e610b53cd4cc7e2c969f15ea6dc7aab8891db66f0ed2131d  guix-build-dfeac76b951f/output/aarch64-linux-gnu/SHA256SUMS.part
 1e992511fece7d724c4b0e2d6153fdcf179b11e7beb07856a4a6206df3a0ebf14  guix-build-dfeac76b951f/output/aarch64-linux-gnu/bitcoin-dfeac76b951f-aarch64-linux-gnu-debug.tar.gz
 29a6bd7181092a4373fe23345b8fa8f2f2bba26ca188f6b28b38161addab82842  guix-build-dfeac76b951f/output/aarch64-linux-gnu/bitcoin-dfeac76b951f-aarch64-linux-gnu.tar.gz
 3a1682fa97dd0212ce2b6269572a16eef0801a822d31c4f15f4d4182277c35f8e  guix-build-dfeac76b951f/output/arm-linux-gnueabihf/SHA256SUMS.part
 418f83a5fe846e4dfa2cbc668d8f20f95675f2118a2f69dee26f1557e6f39b6e6  guix-build-dfeac76b951f/output/arm-linux-gnueabihf/bitcoin-dfeac76b951f-arm-linux-gnueabihf-debug.tar.gz
 568df8efcb6ad1221ba2562e62dac476486b9913ad7a98ccdbef6ce46a316a98e  guix-build-dfeac76b951f/output/arm-linux-gnueabihf/bitcoin-dfeac76b951f-arm-linux-gnueabihf.tar.gz
 67f2de9ef7326e508d9d6eac5b5602eaba3ef736d92bec54199d2746bd1702f67  guix-build-dfeac76b951f/output/arm64-apple-darwin/SHA256SUMS.part
 7da7ffe39a7594206405ede299e752b89310c632e1f4963a0de944ae66dc78de8  guix-build-dfeac76b951f/output/arm64-apple-darwin/bitcoin-dfeac76b951f-arm64-apple-darwin-codesigning.tar.gz
 881fdedf624fea9c904546978789413fb956078c9287a774c1cad5bab2c29ff30  guix-build-dfeac76b951f/output/arm64-apple-darwin/bitcoin-dfeac76b951f-arm64-apple-darwin-unsigned.tar.gz
 9b30a3999e7c56f1771004328b17a18ea8e68a71f1b36638f503a460dab03773e  guix-build-dfeac76b951f/output/arm64-apple-darwin/bitcoin-dfeac76b951f-arm64-apple-darwin-unsigned.zip
1046cf9f6feb036d34d06ae5a2e89819ea2d8da25138b8136aa73c2cf27b97860d  guix-build-dfeac76b951f/output/dist-archive/bitcoin-dfeac76b951f.tar.gz
11a9dce3b2beb4ff664d64c81ec8bb3f8f10273669cecdb853dc5970b610d3bbd5  guix-build-dfeac76b951f/output/powerpc64-linux-gnu/SHA256SUMS.part
122a9ebe7d128284c2bbfd7c0faf54dab96a25034385af86535641f4f8acf0bcae  guix-build-dfeac76b951f/output/powerpc64-linux-gnu/bitcoin-dfeac76b951f-powerpc64-linux-gnu-debug.tar.gz
13ddf9ef24dddf27400695f986d1246b1ead4c64ae7579031f00904603da269567  guix-build-dfeac76b951f/output/powerpc64-linux-gnu/bitcoin-dfeac76b951f-powerpc64-linux-gnu.tar.gz
1420cdcf91105c34bf015649c4bcce21cb9f497d7778753623948bf2c398245418  guix-build-dfeac76b951f/output/riscv64-linux-gnu/SHA256SUMS.part
150c960ba5e695ec57e61e84834a91b158b182b207c4e6b406551b05fb45d873b5  guix-build-dfeac76b951f/output/riscv64-linux-gnu/bitcoin-dfeac76b951f-riscv64-linux-gnu-debug.tar.gz
16f9104c45a60909ff5f3e9698699f924396739b8c3ec37f6dd019da2cd210beb8  guix-build-dfeac76b951f/output/riscv64-linux-gnu/bitcoin-dfeac76b951f-riscv64-linux-gnu.tar.gz
17e077a210853fc54b9d8e7af7a088db35102f0addde05e32c8cd78c383c7720c0  guix-build-dfeac76b951f/output/x86_64-apple-darwin/SHA256SUMS.part
185452fbf7585516640da0057135c44e5218a03e5f62853ec5fdcdba4430403da4  guix-build-dfeac76b951f/output/x86_64-apple-darwin/bitcoin-dfeac76b951f-x86_64-apple-darwin-codesigning.tar.gz
19d8ef48a4237e26949599f361a779e64b49d4bc5fb6b74eaf9bb20e199abf2672  guix-build-dfeac76b951f/output/x86_64-apple-darwin/bitcoin-dfeac76b951f-x86_64-apple-darwin-unsigned.tar.gz
20b3c0803c90bf8ef9769fcbfc4e46e31ada9e199abda3623133a1cf881161a600  guix-build-dfeac76b951f/output/x86_64-apple-darwin/bitcoin-dfeac76b951f-x86_64-apple-darwin-unsigned.zip
21dec0b634c1b191094b3c59fd4ee72eb9a49e09d5932509052b23ee4aafcfb446  guix-build-dfeac76b951f/output/x86_64-linux-gnu/SHA256SUMS.part
2211bad9929586fa4a9fec0604e93e68c6334e9742996bc8758d7131bfa60a26ff  guix-build-dfeac76b951f/output/x86_64-linux-gnu/bitcoin-dfeac76b951f-x86_64-linux-gnu-debug.tar.gz
23a26612548ae96e4415c1e311ec34f58aa06f9536bce77f460372ca24b033f33e  guix-build-dfeac76b951f/output/x86_64-linux-gnu/bitcoin-dfeac76b951f-x86_64-linux-gnu.tar.gz
245986e16ce64f254bb6e6e20edd5319be777e8984c9b59e41d387a5a8c21674d4  guix-build-dfeac76b951f/output/x86_64-w64-mingw32/SHA256SUMS.part
25c860d1a1656e6c0badf0a14a0b1e845b14dca2bc7c7cf6510f4eb229089e8308  guix-build-dfeac76b951f/output/x86_64-w64-mingw32/bitcoin-dfeac76b951f-win64-codesigning.tar.gz
2695ee934bcf0a0a51144397db1c0c2c5c3f5314f4ee43d565bbd173859632b5f4  guix-build-dfeac76b951f/output/x86_64-w64-mingw32/bitcoin-dfeac76b951f-win64-debug.zip
27777972818c858edca8a8e9dccc1ff6f07438a02ea0d18bbf5367c632a6bf229e  guix-build-dfeac76b951f/output/x86_64-w64-mingw32/bitcoin-dfeac76b951f-win64-setup-unsigned.exe
28d14a603d86f81b89d7e76de76a596328425aeef2ea2b91ffb4c5153c25d55675  guix-build-dfeac76b951f/output/x86_64-w64-mingw32/bitcoin-dfeac76b951f-win64-unsigned.zip

w0xlt commented at 11:15 pm on May 8, 2025: contributor

ACK https://github.com/bitcoin/bitcoin/pull/32445/commits/dfeac76b951fc2d28e0832b176f3c8ad595697f1

maflcko commented at 8:50 am on May 9, 2025: member

Not sure if this is worth it. Currently 4 lines of code need to be changed, looking at b537a2c02a9921235d1ecf8c3c7dc1836ec68131. After this, 3 lines will need to be changed. I don’t really see the benefit here.

Whereas this comes with downsides:

People compiling an ancient EOL version/commit will get the impression that they are running a recent release from the current year. This could lead them to thinking they have the latest security patches.
Conversely, people setting a fixed, but ancient SOURCE_DATE_EPOCH may think they are running an EOL version, even though they have the latest security release.
Absent security stuff, the behavior just seems more confusing than before for users.

I understand that bumping user-facing version numbers and year numbers is boring, but they also serve a purpose. If we don’t want that, user-facing version numbers or year numbers should just be removed, but that is probably a larger discussion.

So tend toward NACK for now.

fanquake commented at 9:10 am on May 9, 2025: member

the behavior just seems more confusing than before for users.

Note that historically we’ve produced release binaries that have misleading dates:

0Bitcoin Core version v26.1.0
1Copyright (C) 2009-2023 The Bitcoin Core developers

26.1 was released in April of 2024: https://github.com/bitcoin/bitcoin/releases/tag/v26.1/. I think 28.1 was the first time we’ve ever backported a date bump.

user-facing version numbers or year numbers should just be removed,

As I said above, I don’t care that much, and would be happy to, generally, see dates removed. I don’t see why we’d remove version numbers?

maflcko commented at 9:33 am on May 9, 2025: member

… 2023 … 26.1 was released in April of 2024: https://github.com/bitcoin/bitcoin/releases/tag/v26.1/. I think 28.1 was the first time we’ve ever backported a date bump.

Personally I think it is fine to not bump them for release branches (It is a bit like the Ubuntu release 24.04.2 happening in ‘25). However, it is also fine to bump the year along with the version. CMakeLists.txt will have to be touched anyway for a point release (several times), so touching one line at most once more (per year and per release branch) should be fine as well.

hebasto commented at 10:32 am on May 9, 2025: member

When someone builds from a tarball that is more than a year old, this will use the current year instead of the year of the release.

If this matters, the following patch could help:

 0--- a/.gitattributes
 1+++ b/.gitattributes
 2@@ -1 +1,2 @@
 3+CMakeLists.txt export-subst
 4 src/clientversion.cpp export-subst
 5diff --git a/CMakeLists.txt b/CMakeLists.txt
 6index a1665563cb..d0d24db713 100644
 7--- a/CMakeLists.txt
 8+++ b/CMakeLists.txt
 9@@ -29,6 +29,7 @@ set(CLIENT_VERSION_BUILD 0)
10 set(CLIENT_VERSION_RC 0)
11 set(CLIENT_VERSION_IS_RELEASE "false")
12 string(TIMESTAMP COPYRIGHT_YEAR "%Y" UTC)
13+# git will put "string(SUBSTRING "<top-commit-date>" 0 4 COPYRIGHT_YEAR)" on the next two lines inside archives. $Format:%nstring(SUBSTRING "%cs" 0 4 COPYRIGHT_YEAR)$
14 
15 # During the enabling of the CXX and CXXOBJ languages, we modify
16 # CMake's compiler/linker invocation strings by appending the content

laanwj commented at 11:09 am on May 9, 2025: member

Not sure if this is worth it. Currently 4 lines of code need to be changed, looking at https://github.com/bitcoin/bitcoin/commit/b537a2c02a9921235d1ecf8c3c7dc1836ec68131. After this, 3 lines will need to be changed. I don’t really see the benefit here.

Yeah, i more or less agree. It’s already been condensed to one place, maybe that’s enough.

fanquake closed this on May 9, 2025

fanquake deleted the branch on May 12, 2025

build: let CMake determine the year #32445

Code Coverage & Benchmarks

Reviews