247622 2022-11-08 08:37:03 -0800 Avoid using __TIMESTAMP__ when building for a compilation cache 2023-06-26 13:57:17 -0700 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=252308 https://bugs.webkit.org/show_bug.cgi?id=258517 InRadar P2 Normal --- 1 emw emw alex.kanavin mcatanzaro webkit-bug-importer oldest_to_newest 1911031 0 emw 2022-11-08 08:37:03 -0800 __TIME__, __DATE__, and __TIMESTAMP__ are non-deterministic and interfere with cache reproducibility. 1911033 1 emw 2022-11-08 08:54:39 -0800 <rdar://problem/102056857> 1911034 2 emw 2022-11-08 08:54:54 -0800 Pull request: https://github.com/WebKit/WebKit/pull/6256 1913347 3 ews-feeder 2022-11-17 17:46:37 -0800 Committed 256816@main (adb96155be5e): <https://commits.webkit.org/256816@main> Reviewed commits have been landed. Closing PR #6256 and removing active labels. 1963588 4 alex.kanavin 2023-06-26 03:09:34 -0700 This actually broke reproducibility of cmake-based builds, as (non-reproducible) TIMESTAMP is now injected into binaries where this previously did not happen (look at the changes to CMakeLists.txt in the PR linked to this ticket). 1963646 5 emw 2023-06-26 11:05:36 -0700 > This actually broke reproducibility of cmake-based builds, as (non-reproducible) TIMESTAMP is now injected into binaries where this previously did not happen How was it reproducible before? We used to call `jscBytecodeCacheVersion()` in all builds, which was based on __TIMESTAMP__. My intention was to maintain the status quo for cmake builds, since the checksum-based approach did not seem to be easily compatible with cmake's ninja generator. 1963666 6 mcatanzaro 2023-06-26 13:57:17 -0700 (In reply to Elliott Williams from comment #5) > How was it reproducible before? __TIMESTAMP__ is the file modification time, which was previously fixed but now changes on every build. See bug #252308 and bug #258517.