[Chromecast][BuildFix] Remove circular dependency in GN.

ui/ozone/platform/cast/BUILD.gn

 # Copyright 2015 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.
 
 import("//build/config/chromecast_build.gni")
 import("//ui/ozone/ozone.gni")
 
 # GYP version: cast.gypi:ozone_platform_cast
 # TODO(slan): gn check needs deps on ozone and media to pass. Correct this.
 source_set("cast") {
@@ skipping 21 matching lines @@
   # do not want to statically link against EGL library.
   libs = [ "dl" ]
 
   deps = [
     "//base",
     "//chromecast/graphics:libcast_graphics_1.0",
     "//chromecast/media/base:message_loop",
     "//ui/gfx",
     "//ui/gfx/geometry",
     "//ui/ozone:ozone_base",
-    "//ui/platform_window",

[halliwell, 2015/12/10 21:13:16]

Naively, it looks like PlatformWindowCast needs this.  What am I missing?

[slan, 2015/12/10 21:14:58]

Honestly did no further check than making sure it compiles. Let me dig a little
deeper.

[slan, 2015/12/11 00:13:01]

Just circling back on this now. So here's what's going on:

We are including //u/p/platform_window.h and //u/p/platform_window_delegate.h,
both of which are virtual interfaces. So the headers will be included with our
code, but we do not actually need to depend on any target, because there is no
base class impl to link.

You are right that because we are including this file, gn check should be
complaining that there needs to be a dependency. 
Unfortunately, //ui/ozone is a known mess:
https://code.google.com/p/chromium/codesearch#chromium/src/.gn&l=83

And thus this file is not explicitly whitelisted for gn check, so gn will not
throw a fit when this is removed. All the other platforms likely have the same
issues. This will be corrected when somebody (probably us or CrOS guys) sweeps
through and fixes up all the platforms. This most likely involves making a
"public" target for platform window, or removing the strict dependencies from
ozone => ozone platforms.

Either way, the change is outside the scope of this CL IMO. What do you think?

[spang, 2015/12/11 00:40:26]

This cycle seems to have been added in 
https://codereview.chromium.org/1286383003

Maybe you should file a bug for penghuang to look at?

   ]
 }