Revert overly-wide change in dependency chain. Now the new build step will only be enabled when ...

Revert overly-wide change in dependency chain.  Now the new build step will only be enabled when the optimizations are turned on.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=95916

[Roger McFarlane (Google), 2011-08-08 20:08:13]

Put the dependency chain for chrome back to it's original configuration for the
dev-build scenario (the usual case).

http://codereview.chromium.org/7598008/diff/1/chrome/chrome_dll.gypi
File chrome/chrome_dll.gypi (left):

http://codereview.chromium.org/7598008/diff/1/chrome/chrome_dll.gypi#oldcode156
chrome/chrome_dll.gypi:156: ['fastbuild==0', {
Unfortunately, you're seeing two nearby changes.  The removal of this
fastbuild==0 condition is a different change.  See:

http://codereview.chromium.org/7541080/

This change in in the commit queue.

http://codereview.chromium.org/7598008/diff/1/chrome/chrome_dll_syzygy.gypi
File chrome/chrome_dll_syzygy.gypi (right):

http://codereview.chromium.org/7598008/diff/1/chrome/chrome_dll_syzygy.gypi#n...
chrome/chrome_dll_syzygy.gypi:1: # Copyright (c) 2011 The Chromium Authors. All
rights reserved.
The diffs look worse than they actually are, it's mostly an indentation change
and a deletion of the else clause of a (now redundant) condition.

[Sigurður Ásgeirsson, 2011-08-08 20:10:42]

lgtm

[jam, 2011-08-08 20:11:30]

I defer to other's review on the details, it sounds like this fixes the issue so
lgtm.

[M-A Ruel, 2011-08-08 20:11:33]

lgtm

[mmenke, 2011-08-08 20:15:42]

I also defer to others on the details, but given that it fixes the issue, LGTM. 
Thanks for fixing this.

[Roger McFarlane (Google), 2011-08-08 20:28:26]

My other CL which is inflight (commit-bot tries are complete for linux,
linux_clang, and windows ... mac is on step 24 of 29) will likely result in SVN
merge conflicts if I submit this CL to the commit-bot right now.

I think I have to wait until the bot merges the other change, and push the CL
rebased to the post-merge state (i.e., no files actually change, but the diff
will change).

[Roger McFarlane (Google), 2011-08-08 20:28:50]

This is the other change.

  http://codereview.chromium.org/7541080/

[jam, 2011-08-08 20:32:08]

I'm curious, have you run trybots for the previous change? If not, they
should be run, since the commit bot doesn't run all the try bot changes
(there's a warning dialog for this). If you have, why not just commit
manually?

On Mon, Aug 8, 2011 at 1:28 PM, <rogerm@google.com> wrote:

> My other CL which is inflight (commit-bot tries are complete for linux,
> linux_clang, and windows ... mac is on step 24 of 29) will likely result in
> SVN
> merge conflicts if I submit this CL to the commit-bot right now.
>
> I think I have to wait until the bot merges the other change, and push the
> CL
> rebased to the post-merge state (i.e., no files actually change, but the
> diff
> will change).
>
>
>
http://codereview.chromium.**org/7598008/<http://codereview.chromium.org/7598...
>

[Roger McFarlane (Google), 2011-08-08 20:36:58]

I ran try bots for linux, win, mac manually.  The build steps succeeded for
all, with some random unrelated unit test failing for Mac and Windows.

I've noticed that the try bots seems a bit flaky.

I just received a try-server failure for the other CL on the Mac.

One failure not marked as FAILS or FLAKY somewhere completely unrelated to
my change (which is a NOP on the Mac).

I think I can commit manually using my google creds, but IIRC, that's
verboten.

[Roger McFarlane (Google), 2011-08-08 20:39:19]

I should note that my chromium creds do not have committer rights yet.


On 8 August 2011 16:36, Roger McFarlane <rogerm@google.com> wrote:

> I ran try bots for linux, win, mac manually.  The build steps succeeded for
> all, with some random unrelated unit test failing for Mac and Windows.
>
> I've noticed that the try bots seems a bit flaky.
>
> I just received a try-server failure for the other CL on the Mac.
>
> One failure not marked as FAILS or FLAKY somewhere completely unrelated to
> my change (which is a NOP on the Mac).
>
> I think I can commit manually using my google creds, but IIRC, that's
> verboten.
>

[jam, 2011-08-08 20:39:29]

On Mon, Aug 8, 2011 at 1:36 PM, Roger McFarlane <rogerm@google.com> wrote:

> I ran try bots for linux, win, mac manually.  The build steps succeeded for
> all, with some random unrelated unit test failing for Mac and Windows.
>
> I've noticed that the try bots seems a bit flaky.
>
> I just received a try-server failure for the other CL on the Mac.
>
> One failure not marked as FAILS or FLAKY somewhere completely unrelated to
> my change (which is a NOP on the Mac).
>
> I think I can commit manually using my google creds, but IIRC, that's
> verboten.
>

not at all :) Most changes are still submitted manually, although the long
term goal is CQ. In situations like this, I think it's better to commit
manually since it gets the fix out to developers quicker.

[jam, 2011-08-08 20:40:16]

If you have access to the try bots you should be able to commit manually.

On Mon, Aug 8, 2011 at 1:38 PM, Roger McFarlane <rogerm@google.com> wrote:

> I should note that my chromium creds do not have committer rights yet.
>
>
>
> On 8 August 2011 16:36, Roger McFarlane <rogerm@google.com> wrote:
>
>> I ran try bots for linux, win, mac manually.  The build steps succeeded
>> for all, with some random unrelated unit test failing for Mac and Windows.
>>
>> I've noticed that the try bots seems a bit flaky.
>>
>> I just received a try-server failure for the other CL on the Mac.
>>
>> One failure not marked as FAILS or FLAKY somewhere completely unrelated to
>> my change (which is a NOP on the Mac).
>>
>> I think I can commit manually using my google creds, but IIRC, that's
>> verboten.
>>
>
>

[commit-bot: I haz the power, 2011-08-09 00:02:42]

Change committed as 95916