timestamp of build is incorporated into executable

[Be-ing]

CMakeLists.txt uses CMake's string(TIMESTAMP) feature to put the timestamp of the build into the executable. This makes the build nonreproducible. SOURCE_DATE_EPOCH can be used to hack around this but it's better to not need it. I suggest using the date of the Git commit instead, which can be found with git show --quiet --format=%ci --date=short

[Be-ing]

The date of the commit is printed during CMake's configure stage but it looks like it is only printed for informational purposes? I don't see it used after printing it.

[Paul-Licameli]

A good point, but I will let Leland rule on that.

See where the variable AUDACITY_SUFFIX gets used in cmake-proxies/cmake-modules/AudacityFunctions.cmake and in scripts/CMakeLists.txt.

More generally you can do

find . -name CMakeLists.txt -o -name '*.cmake' | xargs grep AUDACITY_SUFFIX

to find answers to questions like this.

[lllucius]

CMakeLists.txt uses CMake's string(TIMESTAMP) feature to put the timestamp of the build into the executable. This makes the build nonreproducible. SOURCE_DATE_EPOCH can be used to hack around this but it's better to not need it. I suggest using the date of the Git commit instead, which can be found with git show --quiet --format=%ci --date=short

Totally get what you're after and it makes sense. Care to submit a patch or pull request?

[Be-ing]

Care to submit a patch or pull request?

Maybe later. Devendoring dependencies (#853) is a much higher priority.

[henricj]

Isn't the commit time already there?
https://github.com/audacity/audacity/blob/master/cmake-proxies/cmake-modules/Version.cmake

[henricj]

As an aside, while I think repeatable builds are great, it can still be useful to provide the actual build time when the tree is dirty. Speaking of "dirty," the output of "git describe --tags --dirty --always" is also useful thing for the binary to be able to report.

That leaves proper release builds repeatable.

Here's another version of "Version.cmake" that probably takes things too far:
https://github.com/henricj/audacity/blob/x64/cmake-proxies/cmake-modules/Version.cmake

[Be-ing]

it can still be useful to provide the actual build time when the tree is dirty

How so? I really don't know how that information is useful if you have the commit date & time.

[henricj]

it can still be useful to provide the actual build time when the tree is dirty

How so? I really don't know how that information is useful if you have the commit date & time.

Because if a build escapes that is "dirty" then the commit time will not give any insight into what uncomitted--since it is "dirty"--changes have been made. I'm not saying this is necessarily the case with Audacity, but I have certainly had fun with trying to guess what is in a particular build. Usually the file creation and/or modification time survive and can give some clue (or the timestamp field in the PE header--this was back in WinXP days), but that doesn't show up in an automated or semi-automated bug report unless one makes a point of including it.

[Be-ing]

Because if a build escapes that is "dirty" then the commit time will not give any insight into what uncomitted--since it is "dirty"--changes have been made.

If I ever forget what I last compiled, I just compile again. 🤷

@crsib I'm unclear what this has to do with dependency management? This is an issue with the build system.

[crsib]

Hm, I don't really remember adding this, likely I've mistaken it with another bug