Fix up compositor mocking.

Fix up compositor mocking.

Two changes:
a) detangle the mock compositor from compositor_test_support
a) pull in compositor when using a mock compositor

Rationale:

a) this target was meant to support using use_webkit_compositor=1 when WK isn't initialized; sometimes we will want to use the mock compositor when WK is initialized

b) we can imagine scenarios where we want to switch between mock and real compositors in the same executable, and it's one less target to update

BUG=101477
TEST=bots stay green

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

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

[sky, 2011-10-26 15:36:14]

http://codereview.chromium.org/8395043/diff/2002/ui/aura/test/test_suite.cc
File ui/aura/test/test_suite.cc (right):

http://codereview.chromium.org/8395043/diff/2002/ui/aura/test/test_suite.cc#n...
ui/aura/test/test_suite.cc:33: ui::TestCompositor::SetupTestCompositor();
It is possible to only have one initialize/setup call? Maybe it could take
whether you want the test compositor or the real compositor.

http://codereview.chromium.org/8395043/diff/2002/ui/gfx/compositor/compositor...
File ui/gfx/compositor/compositor.gyp (right):

http://codereview.chromium.org/8395043/diff/2002/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor.gyp:59: 'test_compositor.cc',
Why are we compiling these all the time? Shouldn't they only be there for tests?

[jonathan.backer, 2011-10-26 15:58:33]

http://codereview.chromium.org/8395043/diff/2002/ui/aura/test/test_suite.cc
File ui/aura/test/test_suite.cc (right):

http://codereview.chromium.org/8395043/diff/2002/ui/aura/test/test_suite.cc#n...
ui/aura/test/test_suite.cc:33: ui::TestCompositor::SetupTestCompositor();
On 2011/10/26 15:36:15, sky wrote:
> It is possible to only have one initialize/setup call? Maybe it could take
> whether you want the test compositor or the real compositor.

ui::CompositorTestSupport::Initialize() pulls in a dependency that we don't
always want when using ui::TestCompositor::SetupTestCompositor()

which is why they are in two different targets with two different calls. I
imagine that in the longer term (once the WK compositor is extracted from WK),
ui::CompositorTestSupport::Initialize() will disappear entirely.

http://codereview.chromium.org/8395043/diff/2002/ui/gfx/compositor/compositor...
File ui/gfx/compositor/compositor.gyp (right):

http://codereview.chromium.org/8395043/diff/2002/ui/gfx/compositor/compositor...
ui/gfx/compositor/compositor.gyp:59: 'test_compositor.cc',
On 2011/10/26 15:36:15, sky wrote:
> Why are we compiling these all the time? Shouldn't they only be there for
tests?

Mostly being expedient.

The previous GYP setup was flawed in that had .cc files in two different targets
(compositor and compositor_test_support). I could have a new target for
test_compositor that depends on compositor.

Another complication is that test_compositor and compositor_test_support need to
be usable independently (sometimes we want the test_compositor without the
compositor_test_support).

So in short, if I separate I need an additional target: compositor,
test_compositor, and compositor_test_support. I thought it was getting a bit
much.

[sky, 2011-10-26 16:17:35]

On Wed, Oct 26, 2011 at 8:58 AM,  <backer@chromium.org> wrote:
>
> http://codereview.chromium.org/8395043/diff/2002/ui/aura/test/test_suite.cc
> File ui/aura/test/test_suite.cc (right):
>
>
http://codereview.chromium.org/8395043/diff/2002/ui/aura/test/test_suite.cc#n...
> ui/aura/test/test_suite.cc:33:
> ui::TestCompositor::SetupTestCompositor();
> On 2011/10/26 15:36:15, sky wrote:
>>
>> It is possible to only have one initialize/setup call? Maybe it could
>
> take
>>
>> whether you want the test compositor or the real compositor.
>
> ui::CompositorTestSupport::Initialize() pulls in a dependency that we
> don't always want when using ui::TestCompositor::SetupTestCompositor()
>
> which is why they are in two different targets with two different calls.
> I imagine that in the longer term (once the WK compositor is extracted
> from WK), ui::CompositorTestSupport::Initialize() will disappear
> entirely.
>
>
http://codereview.chromium.org/8395043/diff/2002/ui/gfx/compositor/compositor...
> File ui/gfx/compositor/compositor.gyp (right):
>
>
http://codereview.chromium.org/8395043/diff/2002/ui/gfx/compositor/compositor...
> ui/gfx/compositor/compositor.gyp:59: 'test_compositor.cc',
> On 2011/10/26 15:36:15, sky wrote:
>>
>> Why are we compiling these all the time? Shouldn't they only be there
>
> for tests?
>
> Mostly being expedient.
>
> The previous GYP setup was flawed in that had .cc files in two different
> targets (compositor and compositor_test_support). I could have a new
> target for test_compositor that depends on compositor.
>
> Another complication is that test_compositor and compositor_test_support
> need to be usable independently (sometimes we want the test_compositor
> without the compositor_test_support).
>
> So in short, if I separate I need an additional target: compositor,
> test_compositor, and compositor_test_support. I thought it was getting a
> bit much.

We don't want this long term. So, if this is temporary, I'm fine with
it (and file a bug).

  -Scott

[piman, 2011-10-26 16:46:52]

LGTM. thanks for the cleanup.

[jonathan.backer, 2011-10-26 17:58:05]

Addressing reviewer comments.

[piman, 2011-10-26 18:24:09]

lgtm

http://codereview.chromium.org/8395043/diff/2002/ui/aura/aura.gyp
File ui/aura/aura.gyp (right):

http://codereview.chromium.org/8395043/diff/2002/ui/aura/aura.gyp#newcode1
ui/aura/aura.gyp:1: # Copyright (c) 2011 The Chromium Authors. All rights
reserved.
Nit: accidental removal?

[jonathan.backer, 2011-10-26 21:31:01]

One last time (fingers crossed).

We've got three targets:
- compositor
- compositor_test_support
- test_compositor

Whenever compositor_test_support is included as a dependency, either compositor
or test_compositor should be included.

test_compositor depends on compositor _if_ an actual compositor would be
produced. Otherwise it's a no-op (akin to compositor_test_support being a no-op
if use_webkit_compositor == 0).

This should make it fly on mac (the one hold out) and prevent binary bloat for
platforms that don't use the compositor.

the use of ui/gfx/test/gfx_test_utils.(cc|h) is consistent with an earlier
revision of http://codereview.chromium.org/8240006/ that we LGTMed.

http://codereview.chromium.org/8395043/diff/2002/ui/aura/aura.gyp
File ui/aura/aura.gyp (right):

http://codereview.chromium.org/8395043/diff/2002/ui/aura/aura.gyp#newcode1
ui/aura/aura.gyp:1: # Copyright (c) 2011 The Chromium Authors. All rights
reserved.
On 2011/10/26 18:24:09, piman wrote:
> Nit: accidental removal?

Done.

[sky, 2011-10-26 21:40:46]

LGTM I hope this one passes.