use_concatenated_impulse_responses required for grit

use_concatenated_impulse_responses required for grit

If use_concatenated_impulse_responses is set (in config.gni), then
grit needs to have it defined as well.  This is needed to reference
the appropriate response files for the HRTF panner in WebAudio.

BUG=528424
TEST=webaudio panner tests pass

Committed: https://crrev.com/4c50633b258d948b7d28f4bb7af3a787ac8b7079
Cr-Commit-Position: refs/heads/master@{#347534}

[Raymond Toy, 2015-09-04 22:37:18]

rtoy@chromium.org changed reviewers:
+ brettw@chromium.org, dpranke@chromium.org

[Raymond Toy, 2015-09-04 22:37:19]

PTAL.  Not sure about including all of config.gni, but something is needed to
determine if the grit file uses use_concatenated_impulse_response or not.

[Dirk Pranke, 2015-09-04 22:44:47]

lgtm, though it would be nice if there was a better way to deal w/ the grit
issue. Brett?

[brettw, 2015-09-04 23:09:06]

Sadly no, grit sucks.

[brettw, 2015-09-04 23:09:22]

lgtm

[Raymond Toy, 2015-09-04 23:11:50]

On 2015/09/04 at 23:09:22, brettw wrote:
> lgtm

Thanks for the review.

[Raymond Toy, 2015-09-04 23:11:57]

The CQ bit was checked by rtoy@chromium.org

[commit-bot: I haz the power, 2015-09-04 23:12:46]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1311013010/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1311013010/1

[commit-bot: I haz the power, 2015-09-04 23:44:16]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-09-04 23:44:56]

Patchset 1 (id:??) landed as
https://crrev.com/4c50633b258d948b7d28f4bb7af3a787ac8b7079
Cr-Commit-Position: refs/heads/master@{#347534}

[kjellander_chromium, 2015-09-07 12:34:21]

On 2015/09/04 23:44:56, commit-bot: I haz the power wrote:
> Patchset 1 (id:??) landed as
> https://crrev.com/4c50633b258d948b7d28f4bb7af3a787ac8b7079
> Cr-Commit-Position: refs/heads/master@{#347534}

Is there another way to do this? Introducing a dependency on WebKit from the
grit tool effectively prevents WebRTC from re-using the Chromium build toolchain
since we don't want to checkout all of WebKit for our builds.

[Dirk Pranke, 2015-09-07 18:19:58]

On 2015/09/07 12:34:21, kjellander (chromium) wrote:
> On 2015/09/04 23:44:56, commit-bot: I haz the power wrote:
> > Patchset 1 (id:??) landed as
> > https://crrev.com/4c50633b258d948b7d28f4bb7af3a787ac8b7079
> > Cr-Commit-Position: refs/heads/master@{#347534}
> 
> Is there another way to do this? Introducing a dependency on WebKit from the
> grit tool effectively prevents WebRTC from re-using the Chromium build
toolchain
> since we don't want to checkout all of WebKit for our builds.

While I support looking for another way to do this, I'll point out that your
concern
may be moot in a few weeks when we merge blink into the chromium repo.

[Dirk Pranke, 2015-09-08 22:27:14]

On 2015/09/04 23:09:06, brettw wrote:
> Sadly no, grit sucks.

Brett, it looks like if we had set

  grit_flags = ["-D", "use_concatenated_impulse_responses"] 

in //third_party/WebKit/public:resources

it would have the same effect (I tested this and it seems to work).

Is there some reason that wouldn't have been a better patch?

[kjellander_chromium, 2015-09-09 05:53:28]

On 2015/09/07 18:19:58, Dirk Pranke wrote:
> On 2015/09/07 12:34:21, kjellander (chromium) wrote:
> > On 2015/09/04 23:44:56, commit-bot: I haz the power wrote:
> > > Patchset 1 (id:??) landed as
> > > https://crrev.com/4c50633b258d948b7d28f4bb7af3a787ac8b7079
> > > Cr-Commit-Position: refs/heads/master@{#347534}
> > 
> > Is there another way to do this? Introducing a dependency on WebKit from the
> > grit tool effectively prevents WebRTC from re-using the Chromium build
> toolchain
> > since we don't want to checkout all of WebKit for our builds.
> 
> While I support looking for another way to do this, I'll point out that your
> concern
> may be moot in a few weeks when we merge blink into the chromium repo.

That's a good point, I guess we might as well pull down WebKit in addition to
Chromium for now then, to be unblocked.

[brettw, 2015-09-09 15:57:30]

I like Dirk's last idea. This is assuming that the only place that will use this
define is that one target.