Makes GetBuildTime behave sanely on all build types.
After discussion with maruel and agl, it seems that
(1) for the purposes of build determinism, it's necessary
to be able to arbitrarily set the build time.
(2) for the purposes of continuous integration, longer duration
between cache invalidation is better, but >=1mo is preferable.
(3) for security purposes, timebombs would ideally be as close to
the actual time of the build as possible. It must be in the past.
(4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
HTST pinning, <=1mo is preferable.
All of these can reasonably be satisfied by using different settings for CI
versus official builds:
- For official build, the build time is set to 5:00am of the day of the build or
the day before.
- For continuous integration build, the build time is set to the current month.
If the current day is within the first week of the month and last Sunday
wasn't part of the current month, the Sunday of the previous month is used.
This results that cache invalidation happens on a Sunday, which is preferable
from an infrastructure standpoint.
- In the case that the build time needs to be set to a specific value (i.e. to
reproduce a build), the GN/GYP variable 'override_build_date' can be used to
set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
The way it is done is:
- Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
value depends on if an official build is done or not.
- This step depends on build/util/LASTCHANGE so it is run at every sync. The
file is only touched if the content changed to not affect null build.
Most importantly, this change removes the need of both GN/GYP variable
"dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
is always deterministic (up to a month) by default. This removes the risk
oversight of forgetting to set this variable, which already happened.
R=maruel@chromium.org
BUG=489490
Review URL: https://codereview.chromium.org/1641413002
Cr-Original-Commit-Position: refs/heads/master@{#375136}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
|
|
|
#!/usr/bin/env python
|
|
|
|
# Copyright (c) 2016 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.
|
|
|
|
"""Writes a file that contains a define that approximates the build date.
|
|
|
|
|
2016-04-04 23:21:41 +03:00
|
|
|
build_type impacts the timestamp generated:
|
|
|
|
- default: the build date is set to the most recent first Sunday of a month at
|
|
|
|
5:00am. The reason is that it is a time where invalidating the build cache
|
|
|
|
shouldn't have major reprecussions (due to lower load).
|
|
|
|
- official: the build date is set to the current date at 5:00am, or the day
|
|
|
|
before if the current time is before 5:00am.
|
|
|
|
Either way, it is guaranteed to be in the past and always in UTC.
|
Makes GetBuildTime behave sanely on all build types.
After discussion with maruel and agl, it seems that
(1) for the purposes of build determinism, it's necessary
to be able to arbitrarily set the build time.
(2) for the purposes of continuous integration, longer duration
between cache invalidation is better, but >=1mo is preferable.
(3) for security purposes, timebombs would ideally be as close to
the actual time of the build as possible. It must be in the past.
(4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
HTST pinning, <=1mo is preferable.
All of these can reasonably be satisfied by using different settings for CI
versus official builds:
- For official build, the build time is set to 5:00am of the day of the build or
the day before.
- For continuous integration build, the build time is set to the current month.
If the current day is within the first week of the month and last Sunday
wasn't part of the current month, the Sunday of the previous month is used.
This results that cache invalidation happens on a Sunday, which is preferable
from an infrastructure standpoint.
- In the case that the build time needs to be set to a specific value (i.e. to
reproduce a build), the GN/GYP variable 'override_build_date' can be used to
set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
The way it is done is:
- Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
value depends on if an official build is done or not.
- This step depends on build/util/LASTCHANGE so it is run at every sync. The
file is only touched if the content changed to not affect null build.
Most importantly, this change removes the need of both GN/GYP variable
"dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
is always deterministic (up to a month) by default. This removes the risk
oversight of forgetting to set this variable, which already happened.
R=maruel@chromium.org
BUG=489490
Review URL: https://codereview.chromium.org/1641413002
Cr-Original-Commit-Position: refs/heads/master@{#375136}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
|
|
|
|
|
|
|
It is also possible to explicitly set a build date to be used.
|
|
|
|
"""
|
|
|
|
|
|
|
|
import argparse
|
|
|
|
import calendar
|
|
|
|
import datetime
|
2016-04-04 23:21:41 +03:00
|
|
|
import doctest
|
Makes GetBuildTime behave sanely on all build types.
After discussion with maruel and agl, it seems that
(1) for the purposes of build determinism, it's necessary
to be able to arbitrarily set the build time.
(2) for the purposes of continuous integration, longer duration
between cache invalidation is better, but >=1mo is preferable.
(3) for security purposes, timebombs would ideally be as close to
the actual time of the build as possible. It must be in the past.
(4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
HTST pinning, <=1mo is preferable.
All of these can reasonably be satisfied by using different settings for CI
versus official builds:
- For official build, the build time is set to 5:00am of the day of the build or
the day before.
- For continuous integration build, the build time is set to the current month.
If the current day is within the first week of the month and last Sunday
wasn't part of the current month, the Sunday of the previous month is used.
This results that cache invalidation happens on a Sunday, which is preferable
from an infrastructure standpoint.
- In the case that the build time needs to be set to a specific value (i.e. to
reproduce a build), the GN/GYP variable 'override_build_date' can be used to
set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
The way it is done is:
- Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
value depends on if an official build is done or not.
- This step depends on build/util/LASTCHANGE so it is run at every sync. The
file is only touched if the content changed to not affect null build.
Most importantly, this change removes the need of both GN/GYP variable
"dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
is always deterministic (up to a month) by default. This removes the risk
oversight of forgetting to set this variable, which already happened.
R=maruel@chromium.org
BUG=489490
Review URL: https://codereview.chromium.org/1641413002
Cr-Original-Commit-Position: refs/heads/master@{#375136}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
|
|
|
import os
|
|
|
|
import sys
|
|
|
|
|
|
|
|
|
|
|
|
def GetFirstSundayOfMonth(year, month):
|
2016-04-04 23:21:41 +03:00
|
|
|
"""Returns the first sunday of the given month of the given year.
|
|
|
|
|
|
|
|
>>> GetFirstSundayOfMonth(2016, 2)
|
|
|
|
7
|
|
|
|
>>> GetFirstSundayOfMonth(2016, 3)
|
|
|
|
6
|
|
|
|
>>> GetFirstSundayOfMonth(2000, 1)
|
|
|
|
2
|
|
|
|
"""
|
Makes GetBuildTime behave sanely on all build types.
After discussion with maruel and agl, it seems that
(1) for the purposes of build determinism, it's necessary
to be able to arbitrarily set the build time.
(2) for the purposes of continuous integration, longer duration
between cache invalidation is better, but >=1mo is preferable.
(3) for security purposes, timebombs would ideally be as close to
the actual time of the build as possible. It must be in the past.
(4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
HTST pinning, <=1mo is preferable.
All of these can reasonably be satisfied by using different settings for CI
versus official builds:
- For official build, the build time is set to 5:00am of the day of the build or
the day before.
- For continuous integration build, the build time is set to the current month.
If the current day is within the first week of the month and last Sunday
wasn't part of the current month, the Sunday of the previous month is used.
This results that cache invalidation happens on a Sunday, which is preferable
from an infrastructure standpoint.
- In the case that the build time needs to be set to a specific value (i.e. to
reproduce a build), the GN/GYP variable 'override_build_date' can be used to
set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
The way it is done is:
- Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
value depends on if an official build is done or not.
- This step depends on build/util/LASTCHANGE so it is run at every sync. The
file is only touched if the content changed to not affect null build.
Most importantly, this change removes the need of both GN/GYP variable
"dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
is always deterministic (up to a month) by default. This removes the risk
oversight of forgetting to set this variable, which already happened.
R=maruel@chromium.org
BUG=489490
Review URL: https://codereview.chromium.org/1641413002
Cr-Original-Commit-Position: refs/heads/master@{#375136}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
|
|
|
weeks = calendar.Calendar().monthdays2calendar(year, month)
|
|
|
|
# Return the first day in the first week that is a Sunday.
|
|
|
|
return [date_day[0] for date_day in weeks[0] if date_day[1] == 6][0]
|
|
|
|
|
|
|
|
|
|
|
|
def GetBuildDate(build_type, utc_now):
|
2016-04-04 23:21:41 +03:00
|
|
|
"""Gets the approximate build date given the specific build type.
|
|
|
|
|
|
|
|
>>> GetBuildDate('default', datetime.datetime(2016, 2, 6, 1, 2, 3))
|
|
|
|
'Jan 03 2016 01:02:03'
|
|
|
|
>>> GetBuildDate('default', datetime.datetime(2016, 2, 7, 5))
|
|
|
|
'Feb 07 2016 05:00:00'
|
|
|
|
>>> GetBuildDate('default', datetime.datetime(2016, 2, 8, 5))
|
|
|
|
'Feb 07 2016 05:00:00'
|
|
|
|
"""
|
Makes GetBuildTime behave sanely on all build types.
After discussion with maruel and agl, it seems that
(1) for the purposes of build determinism, it's necessary
to be able to arbitrarily set the build time.
(2) for the purposes of continuous integration, longer duration
between cache invalidation is better, but >=1mo is preferable.
(3) for security purposes, timebombs would ideally be as close to
the actual time of the build as possible. It must be in the past.
(4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
HTST pinning, <=1mo is preferable.
All of these can reasonably be satisfied by using different settings for CI
versus official builds:
- For official build, the build time is set to 5:00am of the day of the build or
the day before.
- For continuous integration build, the build time is set to the current month.
If the current day is within the first week of the month and last Sunday
wasn't part of the current month, the Sunday of the previous month is used.
This results that cache invalidation happens on a Sunday, which is preferable
from an infrastructure standpoint.
- In the case that the build time needs to be set to a specific value (i.e. to
reproduce a build), the GN/GYP variable 'override_build_date' can be used to
set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
The way it is done is:
- Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
value depends on if an official build is done or not.
- This step depends on build/util/LASTCHANGE so it is run at every sync. The
file is only touched if the content changed to not affect null build.
Most importantly, this change removes the need of both GN/GYP variable
"dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
is always deterministic (up to a month) by default. This removes the risk
oversight of forgetting to set this variable, which already happened.
R=maruel@chromium.org
BUG=489490
Review URL: https://codereview.chromium.org/1641413002
Cr-Original-Commit-Position: refs/heads/master@{#375136}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
|
|
|
day = utc_now.day
|
|
|
|
month = utc_now.month
|
|
|
|
year = utc_now.year
|
|
|
|
if build_type != 'official':
|
|
|
|
first_sunday = GetFirstSundayOfMonth(year, month)
|
|
|
|
# If our build is after the first Sunday, we've already refreshed our build
|
|
|
|
# cache on a quiet day, so just use that day.
|
|
|
|
# Otherwise, take the first Sunday of the previous month.
|
|
|
|
if day >= first_sunday:
|
|
|
|
day = first_sunday
|
|
|
|
else:
|
|
|
|
month -= 1
|
|
|
|
if month == 0:
|
|
|
|
month = 12
|
|
|
|
year -= 1
|
|
|
|
day = GetFirstSundayOfMonth(year, month)
|
2016-04-04 23:21:41 +03:00
|
|
|
now = datetime.datetime(
|
|
|
|
year, month, day, utc_now.hour, utc_now.minute, utc_now.second)
|
|
|
|
return '{:%b %d %Y %H:%M:%S}'.format(now)
|
Makes GetBuildTime behave sanely on all build types.
After discussion with maruel and agl, it seems that
(1) for the purposes of build determinism, it's necessary
to be able to arbitrarily set the build time.
(2) for the purposes of continuous integration, longer duration
between cache invalidation is better, but >=1mo is preferable.
(3) for security purposes, timebombs would ideally be as close to
the actual time of the build as possible. It must be in the past.
(4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
HTST pinning, <=1mo is preferable.
All of these can reasonably be satisfied by using different settings for CI
versus official builds:
- For official build, the build time is set to 5:00am of the day of the build or
the day before.
- For continuous integration build, the build time is set to the current month.
If the current day is within the first week of the month and last Sunday
wasn't part of the current month, the Sunday of the previous month is used.
This results that cache invalidation happens on a Sunday, which is preferable
from an infrastructure standpoint.
- In the case that the build time needs to be set to a specific value (i.e. to
reproduce a build), the GN/GYP variable 'override_build_date' can be used to
set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
The way it is done is:
- Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
value depends on if an official build is done or not.
- This step depends on build/util/LASTCHANGE so it is run at every sync. The
file is only touched if the content changed to not affect null build.
Most importantly, this change removes the need of both GN/GYP variable
"dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
is always deterministic (up to a month) by default. This removes the risk
oversight of forgetting to set this variable, which already happened.
R=maruel@chromium.org
BUG=489490
Review URL: https://codereview.chromium.org/1641413002
Cr-Original-Commit-Position: refs/heads/master@{#375136}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
|
|
|
|
|
|
|
|
|
|
|
def main():
|
2016-04-04 23:21:41 +03:00
|
|
|
if doctest.testmod()[0]:
|
|
|
|
return 1
|
|
|
|
argument_parser = argparse.ArgumentParser(
|
|
|
|
description=sys.modules[__name__].__doc__,
|
|
|
|
formatter_class=argparse.RawDescriptionHelpFormatter)
|
Makes GetBuildTime behave sanely on all build types.
After discussion with maruel and agl, it seems that
(1) for the purposes of build determinism, it's necessary
to be able to arbitrarily set the build time.
(2) for the purposes of continuous integration, longer duration
between cache invalidation is better, but >=1mo is preferable.
(3) for security purposes, timebombs would ideally be as close to
the actual time of the build as possible. It must be in the past.
(4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
HTST pinning, <=1mo is preferable.
All of these can reasonably be satisfied by using different settings for CI
versus official builds:
- For official build, the build time is set to 5:00am of the day of the build or
the day before.
- For continuous integration build, the build time is set to the current month.
If the current day is within the first week of the month and last Sunday
wasn't part of the current month, the Sunday of the previous month is used.
This results that cache invalidation happens on a Sunday, which is preferable
from an infrastructure standpoint.
- In the case that the build time needs to be set to a specific value (i.e. to
reproduce a build), the GN/GYP variable 'override_build_date' can be used to
set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
The way it is done is:
- Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
value depends on if an official build is done or not.
- This step depends on build/util/LASTCHANGE so it is run at every sync. The
file is only touched if the content changed to not affect null build.
Most importantly, this change removes the need of both GN/GYP variable
"dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
is always deterministic (up to a month) by default. This removes the risk
oversight of forgetting to set this variable, which already happened.
R=maruel@chromium.org
BUG=489490
Review URL: https://codereview.chromium.org/1641413002
Cr-Original-Commit-Position: refs/heads/master@{#375136}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
|
|
|
argument_parser.add_argument('output_file', help='The file to write to')
|
2016-04-04 23:21:41 +03:00
|
|
|
argument_parser.add_argument(
|
|
|
|
'build_type', help='The type of build', choices=('official', 'default'))
|
|
|
|
argument_parser.add_argument(
|
|
|
|
'build_date_override', nargs='?',
|
|
|
|
help='Optional override for the build date. Format must be '
|
|
|
|
'\'Mmm DD YYYY HH:MM:SS\'')
|
Makes GetBuildTime behave sanely on all build types.
After discussion with maruel and agl, it seems that
(1) for the purposes of build determinism, it's necessary
to be able to arbitrarily set the build time.
(2) for the purposes of continuous integration, longer duration
between cache invalidation is better, but >=1mo is preferable.
(3) for security purposes, timebombs would ideally be as close to
the actual time of the build as possible. It must be in the past.
(4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
HTST pinning, <=1mo is preferable.
All of these can reasonably be satisfied by using different settings for CI
versus official builds:
- For official build, the build time is set to 5:00am of the day of the build or
the day before.
- For continuous integration build, the build time is set to the current month.
If the current day is within the first week of the month and last Sunday
wasn't part of the current month, the Sunday of the previous month is used.
This results that cache invalidation happens on a Sunday, which is preferable
from an infrastructure standpoint.
- In the case that the build time needs to be set to a specific value (i.e. to
reproduce a build), the GN/GYP variable 'override_build_date' can be used to
set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
The way it is done is:
- Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
value depends on if an official build is done or not.
- This step depends on build/util/LASTCHANGE so it is run at every sync. The
file is only touched if the content changed to not affect null build.
Most importantly, this change removes the need of both GN/GYP variable
"dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
is always deterministic (up to a month) by default. This removes the risk
oversight of forgetting to set this variable, which already happened.
R=maruel@chromium.org
BUG=489490
Review URL: https://codereview.chromium.org/1641413002
Cr-Original-Commit-Position: refs/heads/master@{#375136}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
|
|
|
args = argument_parser.parse_args()
|
|
|
|
|
|
|
|
if args.build_date_override:
|
2016-04-04 23:21:41 +03:00
|
|
|
# Format is expected to be "Mmm DD YYYY HH:MM:SS".
|
Makes GetBuildTime behave sanely on all build types.
After discussion with maruel and agl, it seems that
(1) for the purposes of build determinism, it's necessary
to be able to arbitrarily set the build time.
(2) for the purposes of continuous integration, longer duration
between cache invalidation is better, but >=1mo is preferable.
(3) for security purposes, timebombs would ideally be as close to
the actual time of the build as possible. It must be in the past.
(4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
HTST pinning, <=1mo is preferable.
All of these can reasonably be satisfied by using different settings for CI
versus official builds:
- For official build, the build time is set to 5:00am of the day of the build or
the day before.
- For continuous integration build, the build time is set to the current month.
If the current day is within the first week of the month and last Sunday
wasn't part of the current month, the Sunday of the previous month is used.
This results that cache invalidation happens on a Sunday, which is preferable
from an infrastructure standpoint.
- In the case that the build time needs to be set to a specific value (i.e. to
reproduce a build), the GN/GYP variable 'override_build_date' can be used to
set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
The way it is done is:
- Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
value depends on if an official build is done or not.
- This step depends on build/util/LASTCHANGE so it is run at every sync. The
file is only touched if the content changed to not affect null build.
Most importantly, this change removes the need of both GN/GYP variable
"dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
is always deterministic (up to a month) by default. This removes the risk
oversight of forgetting to set this variable, which already happened.
R=maruel@chromium.org
BUG=489490
Review URL: https://codereview.chromium.org/1641413002
Cr-Original-Commit-Position: refs/heads/master@{#375136}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
|
|
|
build_date = args.build_date_override
|
|
|
|
else:
|
2016-04-04 23:21:41 +03:00
|
|
|
now = datetime.datetime.utcnow()
|
|
|
|
if now.hour < 5:
|
|
|
|
# The time is locked at 5:00 am in UTC to cause the build cache
|
|
|
|
# invalidation to not happen exactly at midnight. Use the same calculation
|
|
|
|
# as the day before.
|
|
|
|
# See //base/build_time.cc.
|
2016-04-05 03:15:03 +03:00
|
|
|
now = now - datetime.timedelta(days=1)
|
2016-04-04 23:21:41 +03:00
|
|
|
now = datetime.datetime(now.year, now.month, now.day, 5, 0, 0)
|
|
|
|
build_date = GetBuildDate(args.build_type, now)
|
Makes GetBuildTime behave sanely on all build types.
After discussion with maruel and agl, it seems that
(1) for the purposes of build determinism, it's necessary
to be able to arbitrarily set the build time.
(2) for the purposes of continuous integration, longer duration
between cache invalidation is better, but >=1mo is preferable.
(3) for security purposes, timebombs would ideally be as close to
the actual time of the build as possible. It must be in the past.
(4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce
HTST pinning, <=1mo is preferable.
All of these can reasonably be satisfied by using different settings for CI
versus official builds:
- For official build, the build time is set to 5:00am of the day of the build or
the day before.
- For continuous integration build, the build time is set to the current month.
If the current day is within the first week of the month and last Sunday
wasn't part of the current month, the Sunday of the previous month is used.
This results that cache invalidation happens on a Sunday, which is preferable
from an infrastructure standpoint.
- In the case that the build time needs to be set to a specific value (i.e. to
reproduce a build), the GN/GYP variable 'override_build_date' can be used to
set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY".
The way it is done is:
- Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its
value depends on if an official build is done or not.
- This step depends on build/util/LASTCHANGE so it is run at every sync. The
file is only touched if the content changed to not affect null build.
Most importantly, this change removes the need of both GN/GYP variable
"dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build
is always deterministic (up to a month) by default. This removes the risk
oversight of forgetting to set this variable, which already happened.
R=maruel@chromium.org
BUG=489490
Review URL: https://codereview.chromium.org/1641413002
Cr-Original-Commit-Position: refs/heads/master@{#375136}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
|
|
|
|
|
|
|
output = ('// Generated by //build/write_build_date_header.py\n'
|
|
|
|
'#ifndef BUILD_DATE\n'
|
|
|
|
'#define BUILD_DATE "{}"\n'
|
|
|
|
'#endif // BUILD_DATE\n'.format(build_date))
|
|
|
|
|
|
|
|
current_contents = ''
|
|
|
|
if os.path.isfile(args.output_file):
|
|
|
|
with open(args.output_file, 'r') as current_file:
|
|
|
|
current_contents = current_file.read()
|
|
|
|
|
|
|
|
if current_contents != output:
|
|
|
|
with open(args.output_file, 'w') as output_file:
|
|
|
|
output_file.write(output)
|
|
|
|
return 0
|
|
|
|
|
|
|
|
|
|
|
|
if __name__ == '__main__':
|
|
|
|
sys.exit(main())
|