| Summary: | Avoid using __TIMESTAMP__ when building for a compilation cache | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Elliott Williams <emw> |
| Component: | JavaScriptCore | Assignee: | Elliott Williams <emw> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | alex.kanavin, mcatanzaro, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=252308 https://bugs.webkit.org/show_bug.cgi?id=258517 |
||
|
Description
Elliott Williams
2022-11-08 08:37:03 PST
Pull request: https://github.com/WebKit/WebKit/pull/6256 Committed 256816@main (adb96155be5e): <https://commits.webkit.org/256816@main> Reviewed commits have been landed. Closing PR #6256 and removing active labels. 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). > 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.
(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. |