Fix GN builds to include build and patch in Chrome-Proxy header.

Fix GN builds to include build and patch in Chrome-Proxy header.

Previously, GN builds would not properly include the Chromium version
build and patch numbers in the Chrome-Proxy header sent to the Data
Reduction Proxy. This CL fixes this, and adds assertions and tests to
ensure that the build and patch numbers are always present.

BUG=595471
Committed: https://crrev.com/42ff2d30612f173c86a7bf527b246e781d01ec52
Cr-Commit-Position: refs/heads/master@{#381829}

[sclittle, 2016-03-17 21:02:14]

sclittle@chromium.org changed reviewers:
+ bengr@chromium.org

[bengr, 2016-03-17 21:52:04]

lgtm, although I'd be a little surprised if every way the various data reduction
proxy clients are built (cronet, webview, chrome, test shells, etc.) includes a
build and patch.

[sclittle, 2016-03-17 21:52:26]

The CQ bit was checked by sclittle@chromium.org

[commit-bot: I haz the power, 2016-03-17 21:52:49]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1808333002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1808333002/1

[commit-bot: I haz the power, 2016-03-17 23:18:00]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-03-17 23:19:43]

Description was changed from

==========
Fix GN builds to include build and patch in Chrome-Proxy header.

Previously, GN builds would not properly include the Chromium version
build and patch numbers in the Chrome-Proxy header sent to the Data
Reduction Proxy. This CL fixes this, and adds assertions and tests to
ensure that the build and patch numbers are always present.

BUG=595471
==========

to

==========
Fix GN builds to include build and patch in Chrome-Proxy header.

Previously, GN builds would not properly include the Chromium version
build and patch numbers in the Chrome-Proxy header sent to the Data
Reduction Proxy. This CL fixes this, and adds assertions and tests to
ensure that the build and patch numbers are always present.

BUG=595471

Committed: https://crrev.com/42ff2d30612f173c86a7bf527b246e781d01ec52
Cr-Commit-Position: refs/heads/master@{#381829}
==========

[commit-bot: I haz the power, 2016-03-17 23:19:44]

Patchset 1 (id:??) landed as
https://crrev.com/42ff2d30612f173c86a7bf527b246e781d01ec52
Cr-Commit-Position: refs/heads/master@{#381829}

[brucedawson, 2016-03-19 00:24:31]

brucedawson@chromium.org changed reviewers:
+ brucedawson@chromium.org

[brucedawson, 2016-03-19 00:24:32]

I'm not sure whether this matters, but this will provoke some discussion.

https://codereview.chromium.org/1808333002/diff/1/components/data_reduction_p...
File
components/data_reduction_proxy/core/browser/data_reduction_proxy_request_options.cc
(right):

https://codereview.chromium.org/1808333002/diff/1/components/data_reduction_p...
components/data_reduction_proxy/core/browser/data_reduction_proxy_request_options.cc:56:
"PRODUCT_VERSION='" PRODUCT_VERSION "' is badly formed.");
Huh. Interesting fact: VS 2013 cannot compile this expression - it doesn't let
you index into a string constant in a static_assert. This fails, for instance:

#define PRODUCT_VERSION "51.0.2681.0"
void ChromiumVersion() {
  static_assert(PRODUCT_VERSION[0] <= '9', "PRODUCT_VERSION");
}

So this is the first successfully landed CL that requires VS 2015.

[sclittle, 2016-03-19 00:29:46]

https://codereview.chromium.org/1808333002/diff/1/components/data_reduction_p...
File
components/data_reduction_proxy/core/browser/data_reduction_proxy_request_options.cc
(right):

https://codereview.chromium.org/1808333002/diff/1/components/data_reduction_p...
components/data_reduction_proxy/core/browser/data_reduction_proxy_request_options.cc:56:
"PRODUCT_VERSION='" PRODUCT_VERSION "' is badly formed.");
On 2016/03/19 00:24:32, brucedawson wrote:
> Huh. Interesting fact: VS 2013 cannot compile this expression - it doesn't let
> you index into a string constant in a static_assert. This fails, for instance:
> 
> #define PRODUCT_VERSION "51.0.2681.0"
> void ChromiumVersion() {
>   static_assert(PRODUCT_VERSION[0] <= '9', "PRODUCT_VERSION");
> }
> 
> So this is the first successfully landed CL that requires VS 2015.

Wow, I had no idea. I was relying on the CQ to catch any compilation failures
like this - would you recommend that I modify this to work with VS 2013, or do
you think it's fine to leave as-is?

[brucedawson, 2016-03-19 00:32:58]

> Wow, I had no idea. I was relying on the CQ to catch any compilation failures
> like this - would you recommend that I modify this to work with VS 2013, or do
> you think it's fine to leave as-is?

Leave it as is for now. Discussions about when we want to rely on VS 2015 are
already ongoing. There is no VS 2013 try-bot so it was inevitable that this
would happen.