Move targets from src\build_angle.gyp to src\build_angle.gypi

Move targets from src\build_angle.gyp to src\build_angle.gypi

This enables Skia to compile ANGLE

[EricB, 2012-08-29 18:04:32]

Adding daniel@transgaming.com as a reviewer since he was the last to touch this
file.

[dgkoch, 2012-08-29 18:25:13]

This is only used for the Chrome build system. Al or Alok can one of you review
this?

[apatrick1, 2012-08-30 18:05:33]

Eric, can you provide more details about how this lets Skia compile ANGLE and
why? This change looks okay but I worry about WebKit statically linking against
a different version of ANGLE's shader translator and, depending on what you
intend to do, whether there might be any conflicts?

[EricB, 2012-08-30 18:18:28]

On 2012/08/30 18:05:33, apatrick1 wrote:
> Eric, can you provide more details about how this lets Skia compile ANGLE and
> why? This change looks okay but I worry about WebKit statically linking
against
> a different version of ANGLE's shader translator and, depending on what you
> intend to do, whether there might be any conflicts?

Skia's ANGLE build is only used internally for testing.  This is to make sure
we're getting the image results we want and to measure performance, and will not
have any effect in production.

Our internal build system is separate from that of Chrome.  The best way for us
to build ANGLE is to have gyp include this file.  Unfortunately, gyp's behavior
is different depending on the extension, and we need it to be a gypi.

[apatrick1, 2012-08-30 18:41:48]

Why does this not work? In your Skia .gyp file add this to whatever target needs
ANGLE.

'targets': [
  ...
  {
    'target_name': 'foo',
    ...
    'dependencies': [
      'path/to/src/build_angle.gyp:libEGL',
      'path/to/src/build_angle.gyp:libGLESv2',
    ],
    ...
  },
]

I don't understand why you need to include a gypi file when a reference from the
dependencies of a target will read a gyp file.

[EricB, 2012-08-30 18:48:02]

On 2012/08/30 18:41:48, apatrick1 wrote:
> Why does this not work? In your Skia .gyp file add this to whatever target
needs
> ANGLE.
> 
> 'targets': [
>   ...
>   {
>     'target_name': 'foo',
>     ...
>     'dependencies': [
>       'path/to/src/build_angle.gyp:libEGL',
>       'path/to/src/build_angle.gyp:libGLESv2',
>     ],
>     ...
>   },
> ]
> 
> I don't understand why you need to include a gypi file when a reference from
the
> dependencies of a target will read a gyp file.

That pattern does indeed work when the .gyp file is in the *same directory*. 
However, depending on a target inside a .gyp file in another directory causes
the resulting Visual Studio solutions to try to impose a directory structure of
projects, which we are unable to build from the command line.  For more, see:
http://code.google.com/p/skia/issues/detail?id=543

[apatrick1, 2012-08-30 19:44:01]

LGTM if the suggestion below does not work or if you have tried it already.

Skia appears to be using a copy of gyp revision r197, which makes it more than
three years old. See trunk/third_party/gyp/README.skia. The most recent revision
of gyp is r1488: http://code.google.com/p/gyp/source/list

If you haven't tried already, can you try updating Skia's gyp to a more recent
version and see if that fixes things?

[EricB, 2012-08-30 20:13:10]

On 2012/08/30 19:44:01, apatrick1 wrote:
> LGTM if the suggestion below does not work or if you have tried it already.
> 
> Skia appears to be using a copy of gyp revision r197, which makes it more than
> three years old. See trunk/third_party/gyp/README.skia. The most recent
revision
> of gyp is r1488: http://code.google.com/p/gyp/source/list
> 
> If you haven't tried already, can you try updating Skia's gyp to a more recent
> version and see if that fixes things?

Where are you seeing r197?  Our DEPS file is using revision 1320:
https://code.google.com/p/skia/source/browse/trunk/DEPS.  At any rate, I updated
to 1488 and tried again with the same result - failure unless I include a .gypi.

[apatrick1, 2012-08-30 20:32:05]

I'm having trouble getting something that resembles a permanent link. See if
this works:
http://code.google.com/searchframe#gW4d001uW-I/trunk/third_party/gyp/README.skia
.

The file says:

"This is a snap of GYP (http://code.google.com/p/gyp/) at r197

svn export http://gyp.googlecode.com/svn/trunk/

The following were omitted:
DEPS
MANIFEST
PRESUBMIT.py
codereview.settings
gyp_dummy.c
gyptest.py
test/
samples/
tools/"

Maybe that's not what Skia is actually using? I see the more up to date revision
in the DEPS file too.

[EricB, 2012-08-30 20:44:00]

On 2012/08/30 20:32:05, apatrick1 wrote:
> I'm having trouble getting something that resembles a permanent link. See if
> this works:
>
http://code.google.com/searchframe#gW4d001uW-I/trunk/third_party/gyp/README.skia
> .
> 
> The file says:
> 
> "This is a snap of GYP (http://code.google.com/p/gyp/) at r197
> 
> svn export http://gyp.googlecode.com/svn/trunk/
> 
> The following were omitted:
> DEPS
> MANIFEST
> PRESUBMIT.py
> codereview.settings
> gyp_dummy.c
> gyptest.py
> test/
> samples/
> tools/"
> 
> Maybe that's not what Skia is actually using? I see the more up to date
revision
> in the DEPS file too.

That site seems to be very out-of-date, and I'm not sure why.  Looks like our
gyp revision is at 1284 in out svn properties and 1320 in DEPS, with revision
1284 actually checked out.  I'm going to roll those forward to be in sync at
1488, but that didn't fix this problem.

[apatrick1, 2012-08-30 20:54:45]

Thanks for checking. LGTM.

[EricB, 2012-08-30 20:56:39]

On 2012/08/30 20:54:45, apatrick1 wrote:
> Thanks for checking. LGTM.

No problem.  I guess I need a committer to commit on my behalf?

[apatrick1, 2012-08-30 21:16:10]

I tested it locally and committed.
https://codereview.appspot.com/6492063/