Add Skia to the GN build.

Add Skia to the GN build.

This makes the GN build of Skia compile and adds it to the GN build.
Previously, the configuration of the GN Skia tried to match the confusing array
of skia targets. This new version dispenses with that and just adds all files
(except SSE ones) to one target. I'm not even sure if it's necessary to split
out the SSE ones, but it seems nice since that target will get more complicated
when we add Arm and MIPS support.

I audited the defines again and added some to the main build config that had
been added to the GYP build recently.

This improves some operator error messages that I found confusing when I had errors in my file.

BUG=
R=djsollen@google.com, scottmg@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=262779

[scottmg, 2014-04-02 16:59:23]

lgtm

[scottmg, 2014-04-02 17:03:22]

https://codereview.chromium.org/214883005/diff/1/tools/gn/operators.cc
File tools/gn/operators.cc (right):

https://codereview.chromium.org/214883005/diff/1/tools/gn/operators.cc#newcod...
tools/gn/operators.cc:421: "\" instead.");
do these need the AppendRange still?

[brettw, 2014-04-02 17:06:01]

https://codereview.chromium.org/214883005/diff/1/tools/gn/operators.cc
File tools/gn/operators.cc (right):

https://codereview.chromium.org/214883005/diff/1/tools/gn/operators.cc#newcod...
tools/gn/operators.cc:421: "\" instead.");
No. I don't know what I was thinking with this before. The new error location
indication looks correct now.

[brettw, 2014-04-03 20:30:20]

+Derek for SKia

[djsollen, 2014-04-04 12:36:11]

Unfortunately, the Skia gyp is currently not able to have one large target
because of how we are used by the Android WebView.  The WebView can set
use_system_skia=1 at which point they dynamically link against the copy of Skia
on the device instead of statically linking.  It gets convoluted because we
still need to build the chromium specific parts of Skia (e.g. the contents of
skia/ext/).  I'm not familiar enough with GN at this point to know how to
emulate that behavior or perhaps we don't need to emulate it yet if the WebView
is not going to be using GN at this time.

[brettw, 2014-04-04 16:43:04]

On 2014/04/04 12:36:11, djsollen wrote:
> Unfortunately, the Skia gyp is currently not able to have one large target
> because of how we are used by the Android WebView.  The WebView can set
> use_system_skia=1 at which point they dynamically link against the copy of
Skia
> on the device instead of statically linking.  It gets convoluted because we
> still need to build the chromium specific parts of Skia (e.g. the contents of
> skia/ext/).  I'm not familiar enough with GN at this point to know how to
> emulate that behavior or perhaps we don't need to emulate it yet if the
WebView
> is not going to be using GN at this time.

The current build is not going to be used by webview. We can fix it later or
have a separate build for webview. I kept most of the types of source files
separate so we can be flexible about this.

It's much easier to move stuff around in the GN build. A lot of the complexity
in the current Skia GYP build is to make one big target when doing a component
build in Chrome because otherwise the exports get mangled. But this is trivial
to avoid using GN's source set, so I don't think this makes anything harder
later.

[brettw, 2014-04-08 23:48:48]

Any other comments? I'd like to get this in soon since it's blocking any more ui
work.

[djsollen, 2014-04-09 14:22:26]

https://codereview.chromium.org/214883005/diff/80001/skia/skia_gn_files.gypi
File skia/skia_gn_files.gypi (right):

https://codereview.chromium.org/214883005/diff/80001/skia/skia_gn_files.gypi#...
skia/skia_gn_files.gypi:26: 'skia_gpu_sources': [
can you do something like...

'skia_gpu_sources': [
  'includes': [
    '../third_party/skia/gyp/gpu.gypi',
  ],
],

That way we won't break the ninja build when we add/remove files from there. 
That way we only have to maintain dual GYP/GN changes for those
sources/defines/options not in a skia *.gypi files.

[brettw, 2014-04-09 16:22:43]

https://codereview.chromium.org/214883005/diff/80001/skia/skia_gn_files.gypi
File skia/skia_gn_files.gypi (right):

https://codereview.chromium.org/214883005/diff/80001/skia/skia_gn_files.gypi#...
skia/skia_gn_files.gypi:26: 'skia_gpu_sources': [
No.

This file is not processed by GYP. It's read into a Python dictionary into GN
which only understands how to read python dictionaries, not execute GYP code.

The idea of this file list is that you guys would move it to your tree and
reference it from the existing GYP build using includes.

[djsollen, 2014-04-09 17:33:32]

lgtm on the skia dictionaries! I'll work on getting those dictionaries rolled
into Skia so that we can avoid breakages when files are added/removed.

[brettw, 2014-04-09 19:55:33]

Committed patchset #5 manually as r262779 (presubmit successful).

[tfarina, 2014-04-12 02:27:13]

https://codereview.chromium.org/214883005/diff/80001/BUILD.gn
File BUILD.gn (right):

https://codereview.chromium.org/214883005/diff/80001/BUILD.gn#newcode33
BUILD.gn:33: #"//skia",
you forgot to remove this :)

or just uncomment instead of adding at line 38.

I will include this "fix" in my https://codereview.chromium.org/230073003/ CL.

[brettw, 2014-04-12 04:42:39]

https://codereview.chromium.org/214883005/diff/80001/BUILD.gn
File BUILD.gn (right):

https://codereview.chromium.org/214883005/diff/80001/BUILD.gn#newcode33
BUILD.gn:33: #"//skia",
On 2014/04/12 02:27:13, tfarina wrote:
> you forgot to remove this :)
> 
> or just uncomment instead of adding at line 38.
> 
> I will include this "fix" in my https://codereview.chromium.org/230073003/ CL.

sounds good, thanks