Roll //build, //native_client, and a few more targets of opportunity.

Roll //build, //native_client, and a few more targets of opportunity.

Update from https://crrev.com/327068

Evolution of GN has changed //build, and NaCl requires the new version.
Two .gn files needed to be modified to change "os" to "current_os".

//base is not rolled because it is intertwined with //gpu and there is no
longer a simple way to update //gpu.

BUG=401761

[Nick Bray (chromium), 2015-04-27 22:26:25]

ncbray@chromium.org changed reviewers:
+ jamesr@chromium.org

[Nick Bray (chromium), 2015-04-27 22:26:26]

It looks like the bots are having goma issues, I'll re-run the try jobs later to
see if it's transient.

[jamesr, 2015-04-27 22:31:27]

The patch description says this patch isn't rolling //base but I see a buncha
new files - is this deliberate?  Maybe you reverted changes to existing files
but left new files in place?  I'm seeing new source files but not modifications
to BUILD.gn files so something seems amiss.

https://codereview.chromium.org/1108173002/diff/1/DEPS
File DEPS (right):

https://codereview.chromium.org/1108173002/diff/1/DEPS#newcode60
DEPS:60: Var('chromium_git') + '/chromium/deps/icu.git' + '@' +
'10834e84d250eb31a73496bfdb7923eaa43ead51',
i know icu is a dependency of //base, but if you aren't rolling that why do you
need a new one?

https://codereview.chromium.org/1108173002/diff/1/DEPS#newcode63
DEPS:63: Var('chromium_git') + '/external/grit-i18n.git' + '@' +
'c1b1591a05209c1ad467e845ba8543c22f9072af', # from svn revision 189
what needs/wants a new version of grit?

https://codereview.chromium.org/1108173002/diff/1/DEPS#newcode91
DEPS:91: Var('chromium_git') + '/chromium/deps/libjpeg_turbo.git' + '@' +
'9e9058be139a32f2d03eddce97fb15ecca92e6bc',
what needs a new libjpeg_turbo?

[jamesr, 2015-04-27 22:34:40]

Also please update the patch description to cover //sandbox/linux.  If you want
to roll it, that's great - please say that in the desc.  If you don't, that's
fine too but please back out the changes to it if you aren't rolling.

https://codereview.chromium.org/1108173002/diff/1/mojo/tools/roll/roll_networ...
File mojo/tools/roll/roll_network_service_patches/network_service.patch (left):

https://codereview.chromium.org/1108173002/diff/1/mojo/tools/roll/roll_networ...
mojo/tools/roll/roll_network_service_patches/network_service.patch:1: diff --git
a/mojo/services/network/public/interfaces/BUILD.gn
b/mojo/services/network/public/interfaces/BUILD.gn
I believe we still need this file.  It's used by
mojo/tools/roll/roll_network_service.py

[jamesr, 2015-04-27 22:35:36]

Also put the revision you're getting the files pulled from chromium from in the
patch description.  The roll script should generate a string like 'Update from
https://crrev.com/123456' where '123456' is the cr-commit-position

[jamesr, 2015-05-05 17:25:08]

Nick - I'd like to update to a newer rev of build.  Would you mind if I took
this patch as a base, landed it, then did a further roll on top of it?  I would
be taking this patch, cleaning out the unrelated file adds and adding a
description with more information that cited this one.

[Nick Bray (chromium), 2015-05-05 18:01:31]

On 2015/05/05 17:25:08, jamesr wrote:
> Nick - I'd like to update to a newer rev of build.  Would you mind if I took
> this patch as a base, landed it, then did a further roll on top of it?  I
would
> be taking this patch, cleaning out the unrelated file adds and adding a
> description with more information that cited this one.

Go for it.  I had to let it sit for a while because it was excessively painful. 
I was going to get back to it today, but will happily let you do it.  I am not
sure if you want to base the patch on this or start from scratch.

GN requires "os" to be updated to "current_os", which is why I needed to do this
roll in the first place.

The only trick, so far, is to no roll //base except for:
base/android/java/src/org/chromium/base/PathUtils.java

Rolling //base makes //gpu go awful, but feel free to take a swing at that if
you want.

There's still a messy interaction between //build, //testing, //tools and the
BUILD.gn files from Chrome that aren't being rolled.  Currently the problem is
that tools/grit/grit.py has changed, and some of the build gunk in ui/android
depends on the old command line?  That was the next thing I was going to hack
on.

[jamesr, 2015-05-05 18:26:22]

On 2015/05/05 18:01:31, Nick Bray (chromium) wrote:
> On 2015/05/05 17:25:08, jamesr wrote:
> > Nick - I'd like to update to a newer rev of build.  Would you mind if I took
> > this patch as a base, landed it, then did a further roll on top of it?  I
> would
> > be taking this patch, cleaning out the unrelated file adds and adding a
> > description with more information that cited this one.
> 
> Go for it.  I had to let it sit for a while because it was excessively
painful. 
> I was going to get back to it today, but will happily let you do it.  I am not
> sure if you want to base the patch on this or start from scratch.

Got it, no argument there.

> 
> GN requires "os" to be updated to "current_os", which is why I needed to do
this
> roll in the first place.
> 
> The only trick, so far, is to no roll //base except for:
> base/android/java/src/org/chromium/base/PathUtils.java
> 
> Rolling //base makes //gpu go awful, but feel free to take a swing at that if
> you want.

I'd like to try this separately but I'm not sure how feasible that'll be

> 
> There's still a messy interaction between //build, //testing, //tools and the
> BUILD.gn files from Chrome that aren't being rolled.  Currently the problem is
> that tools/grit/grit.py has changed, and some of the build gunk in ui/android
> depends on the old command line?  That was the next thing I was going to hack
> on.

OK, thanks for the heads up.

[jamesr, 2015-05-05 21:15:20]

Updating //base as well turns out to be not very hard, so what I'll do is land a
patch that updates //build + //base + //sandbox/linux in a way similar to this
patch to the same chromium rev and then as a separate patch update
//native_client, then work on a follow-up patch to pull //base + //build +
//sandbox/linux to ToT.  Would you also like a newer //native_client than the
one this one targets?

[Nick Bray (chromium), 2015-05-05 21:21:16]

On 2015/05/05 21:15:20, jamesr wrote:
> Updating //base as well turns out to be not very hard, so what I'll do is land
a
> patch that updates //build + //base + //sandbox/linux in a way similar to this
> patch to the same chromium rev and then as a separate patch update
> //native_client, then work on a follow-up patch to pull //base + //build +
> //sandbox/linux to ToT.  Would you also like a newer //native_client than the
> one this one targets?

I believe //native_client is coupled with //build (os vs. current_os) so you
can't avoid rolling it?  I don't care about the particular version of
//native_client, just that I can roll it to ToT when I add a few new public
APIs.

[jamesr, 2015-05-05 21:22:47]

On 2015/05/05 21:21:16, Nick Bray (chromium) wrote:
> On 2015/05/05 21:15:20, jamesr wrote:
> > Updating //base as well turns out to be not very hard, so what I'll do is
land
> a
> > patch that updates //build + //base + //sandbox/linux in a way similar to
this
> > patch to the same chromium rev and then as a separate patch update
> > //native_client, then work on a follow-up patch to pull //base + //build +
> > //sandbox/linux to ToT.  Would you also like a newer //native_client than
the
> > one this one targets?
> 
> I believe //native_client is coupled with //build (os vs. current_os) so you
> can't avoid rolling it?  I don't care about the particular version of
> //native_client, just that I can roll it to ToT when I add a few new public
> APIs.

Ah, you may be right.  I thought I was doing nacl builds by default so I should
be seeing issues locally but that very well be PEBKAC.  I can definitely roll
//native_client at the same time.

[jamesr, 2015-05-05 21:24:14]

On 2015/05/05 21:22:47, jamesr wrote:
> On 2015/05/05 21:21:16, Nick Bray (chromium) wrote:
> > On 2015/05/05 21:15:20, jamesr wrote:
> > > Updating //base as well turns out to be not very hard, so what I'll do is
> land
> > a
> > > patch that updates //build + //base + //sandbox/linux in a way similar to
> this
> > > patch to the same chromium rev and then as a separate patch update
> > > //native_client, then work on a follow-up patch to pull //base + //build +
> > > //sandbox/linux to ToT.  Would you also like a newer //native_client than
> the
> > > one this one targets?
> > 
> > I believe //native_client is coupled with //build (os vs. current_os) so you
> > can't avoid rolling it?  I don't care about the particular version of
> > //native_client, just that I can roll it to ToT when I add a few new public
> > APIs.
> 
> Ah, you may be right.  I thought I was doing nacl builds by default so I
should
> be seeing issues locally but that very well be PEBKAC.  I can definitely roll
> //native_client at the same time.

Ah yup, had the flag flipped the wrong way.  I'll update to the same
nacl_revision this patch targets.