chromium-src-build/timestamp.gni

24 строки
896 B
Plaintext
Исходник Обычный вид История

Reland "win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time" This reverts commit 2df0c83aee0a00bc0f7c26a22b68b4ea3eefef80. Reason for revert: official android should be fine with this after #583420 Original change's description: > Revert "win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time" > > This reverts commit ef36dc19986a90f49d0d31520c88d310d72bd038. > > Reason for revert: This turns out to break the official android build, which apparently was relying on a broken aspect of the build that this fixed :(. See https://crbug.com/871173. > > Original change's description: > > win: write a deterministic-ish timestamp into the PE/COFF header instead of the current time > > > > We used to set the timestamp to a hash of the binary, similar to > > https://blogs.msdn.microsoft.com/oldnewthing/20180103-00/?p=97705 > > However, that caused an appcompat warning on Windows 7 to appear, which > > interpreted the hash as a timestamp. (It's possible that https://llvm.org/PR38429 > > could help with that, but my guess it won't have an effect on Windows 7, > > which likely always believes that the the coff timestamp field always stores > > a timestamp). > > > > So currently we write the current time during linking in that field, but that's > > bad for build determinism and that in turn is bad for swarming test result cachability. > > > > build/write_build_date_header.py already creates a deterministic BUILD_DATE > > with several tradeoffs. Cachability wants this to change infrequently, but > > things like HSTS need a "real" build date and want this to change frequently. > > The compromise is: The date changes once per day in official builds, and > > once a month in regular builds. > > > > (We could use /Brepro in ldflags instead of /TIMESTAMP for unofficial builds to get > > the binary hash in the timestamp, but having the header timestamp match the BUILD_DATE > > define seems nice.) > > > > So let's use that same time as timestamp in the PE/COFF header. lld-link has a > > /TIMESTAMP: flag we can use to pass in an explicit timestamp. > > > > Since tools can't have deps, we need to compute the timestamp at gn time, > > so split write_build_date_header.py in two pieces: build/compute_build_timestamp.py > > that just prints the timestamp we want to use, and the old write_build_date_header.py, which > > now takes that timestamp and writes the header file. > > > > Call compute_build_timestamp.py at gn time so that we can pass it in ldflags, and > > pass the resultl to write_build_date_header.py which keeps running as an action > > during build time (so that we at least don't need to write a file at gn time). > > > > An additional wrinkle here is that the PE/COFF timestamp is used as one of just two > > keys per binary for uploading PE binaries to the symbol server, the other being file size. > > https://bugs.llvm.org/show_bug.cgi?id=35914#c0 has a good description of this, and > > tools/symsrc/img_fingerprint.py's GetImgFingerprint() is our implementation of it. > > But since we only upload binaries with symbols for official chrome builds to the symbol server, > > a timestamp that changes once a day should be still enough. (32-bit and 64-bit chromes > > have the same filename, and we might rarely build canary and beta and stable all on the > > same day, but them all being the same size seems highly unlikely.) > > > > Bug: 843199,804926,330260 > > Change-Id: I1d4193cc537ae0c4b2d6ac9281fad29de754dd6c > > Reviewed-on: https://chromium-review.googlesource.com/1161104 > > Reviewed-by: Dirk Pranke <dpranke@chromium.org> > > Reviewed-by: Hans Wennborg <hans@chromium.org> > > Commit-Queue: Nico Weber <thakis@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#580585} > > TBR=thakis@chromium.org,hans@chromium.org,dpranke@chromium.org > NOTRY=true > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: 843199, 804926, 330260 > Change-Id: Ib93697a82f8a9d3fb303b763609e82e0612887cd > Reviewed-on: https://chromium-review.googlesource.com/1166203 > Commit-Queue: Hans Wennborg <hans@chromium.org> > Reviewed-by: Dirk Pranke <dpranke@chromium.org> > Reviewed-by: Nico Weber <thakis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#581485} TBR=thakis@chromium.org,hans@chromium.org,dpranke@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 843199, 804926, 330260 Change-Id: I136e405c84eba3f61a4ac96b2017a34ade0cfba6 Reviewed-on: https://chromium-review.googlesource.com/1179281 Commit-Queue: Nico Weber <thakis@chromium.org> Reviewed-by: Nico Weber <thakis@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#583945} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 967d1f1e6adc9b7641a5b0174c48f0883e293880
2018-08-17 05:42:02 +03:00
# Copyright 2018 The Chromium Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
#
# Defines the build_timestamp variable.
import("//build/util/lastchange.gni")
if (is_official_build) {
official_name = "official"
} else {
official_name = "default"
}
# This will return a timestamp that's different each day (official builds)
# of each month (regular builds). Just rely on gn rerunning due to other
# changes to keep this up to date. (Bots run gn on each build, and for devs
# the timestamp being 100% accurate doesn't matter.)
# See compute_build_timestamp.py for tradeoffs for picking the timestamp.
build_timestamp = exec_script("compute_build_timestamp.py",
[ official_name ],
"trim string",
[ lastchange_file ])