Refactor the bench and common gyp/gypi files to allow for building bench within

Refactor the bench and common gyp/gypi files to allow for building bench within
a chromium checkout (using chromium build configuration).

BUG=362
TEST=Build bench from within the chromium and skia source tree, ensured it built
     and ran successfully.
Committed: http://code.google.com/p/skia/source/detail?r=2270

[seanpaul, 2011-09-14 15:56:11]

PTAL

[bungeman, 2011-09-14 16:10:52]

On 2011/09/14 15:56:11, seanpaul wrote:
> PTAL

LGTM

[bsalomon, 2011-09-14 17:19:08]

On 2011/09/14 16:10:52, bungeman wrote:
> On 2011/09/14 15:56:11, seanpaul wrote:
> > PTAL
> 
> LGTM

LGTM

[epoger, 2011-09-14 17:48:45]

On 2011/09/14 17:19:08, bsalomon wrote:
> On 2011/09/14 16:10:52, bungeman wrote:
> > On 2011/09/14 15:56:11, seanpaul wrote:
> > > PTAL
> > 
> > LGTM
> 
> LGTM

I'm glad to see that this works, but at the same time I'm not happy with the
overarching direction (adding yet another layer of complexity to an
already-complex build system).

I would rather see us go in the direction of skia providing one or two main gyp
files that any skia-dependent software package can depend on to build commonly
useful targets.

What's the use case here?  Who wants to build bench within a chromium checkout?

[bsalomon, 2011-09-14 17:53:51]

On Wed, Sep 14, 2011 at 1:48 PM, <epoger@google.com> wrote:

> On 2011/09/14 17:19:08, bsalomon wrote:
>
>> On 2011/09/14 16:10:52, bungeman wrote:
>> > On 2011/09/14 15:56:11, seanpaul wrote:
>> > > PTAL
>> >
>> > LGTM
>>
>
>  LGTM
>>
>
> I'm glad to see that this works, but at the same time I'm not happy with
> the overarching direction (adding yet another layer of complexity to an
> already-complex build system).
>
> I would rather see us go in the direction of skia providing one or two
> main gyp files that any skia-dependent software package can depend on to
> build commonly useful targets.
>
> What's the use case here?  Who wants to build bench within a chromium
> checkout?
>
>
>
http://codereview.appspot.com/**5023042/<http://codereview.appspot.com/5023042/>
>


The goal is to build bench within a CrOS checkout in order to assess
performance. We'd like to benchmark the skia lib as built for chrome, with
its decisions about what #define flags to set, optional files to build, and
compiler flags.

[epoger, 2011-09-14 18:15:21]

On 2011/09/14 17:53:51, bsalomon wrote:
> On Wed, Sep 14, 2011 at 1:48 PM, <mailto:epoger@google.com> wrote:
> 
> > On 2011/09/14 17:19:08, bsalomon wrote:
> >
> >> On 2011/09/14 16:10:52, bungeman wrote:
> >> > On 2011/09/14 15:56:11, seanpaul wrote:
> >> > > PTAL
> >> >
> >> > LGTM
> >>
> >
> >  LGTM
> >>
> >
> > I'm glad to see that this works, but at the same time I'm not happy with
> > the overarching direction (adding yet another layer of complexity to an
> > already-complex build system).
> >
> > I would rather see us go in the direction of skia providing one or two
> > main gyp files that any skia-dependent software package can depend on to
> > build commonly useful targets.
> >
> > What's the use case here?  Who wants to build bench within a chromium
> > checkout?
> >
> >
> >
>
http://codereview.appspot.com/**5023042/%3Chttp://codereview.appspot.com/5023...>
> >
> 
> 
> The goal is to build bench within a CrOS checkout in order to assess
> performance. We'd like to benchmark the skia lib as built for chrome, with
> its decisions about what #define flags to set, optional files to build, and
> compiler flags.

LGTM then.  If I were a stickler for such things, I would say "where's the bug
indicating the need for this"?  Luckily I'm not.  Or am I?