Fix componene debug build failure because of src/media/blink

Fix componene debug build failure because of src/media/blink

The error log is as follows:
../../third_party/skia/include/core/SkImageInfo.h:109: error: undefined reference to 'SkDebugf_FileLine(char const*, int, bool, char const*, ...)'
collect2: error: ld returned 1 exit status

If any modules are going to use any Skia header no matter whether directly or
indirectly, the module must link Skia. src/media/blink doesn't depend on skia
directly but src/media, on which src/media/blink depends, depends on Skia. So
src/media/blink must link to Skia.

Committed: https://crrev.com/5192601b41aff92488b9a458fc50dedda48507ac
Cr-Commit-Position: refs/heads/master@{#314554}

[dshwang, 2015-01-30 21:52:54]

dongseong.hwang@intel.com changed reviewers:
+ mtklein@google.com, reed@chromium.org, scherkus@chromium.org

[dshwang, 2015-01-30 21:52:55]

@scherkus, could you review?

currently linux cannot build chromium by debug component build.
This CL is created after discussion in
https://codereview.chromium.org/870023002/

[mtklein_C, 2015-01-30 21:54:29]

mtklein@chromium.org changed reviewers:
+ mtklein@chromium.org

[mtklein_C, 2015-01-30 21:54:30]

Why don't you have the thing that depends on Skia export that dependency to its
dependents?

[mtklein_C, 2015-01-30 21:56:38]

On 2015/01/30 21:54:30, mtklein_C wrote:
> Why don't you have the thing that depends on Skia export that dependency to
its
> dependents?

Or really, have the Skia target export the need to link Skia to anything that
depends on it?

[DaleCurtis, 2015-01-30 22:00:14]

dalecurtis@chromium.org changed reviewers:
+ dalecurtis@chromium.org

[DaleCurtis, 2015-01-30 22:00:14]

Yeah, dependent modules shouldn't need to be modified, they should export a
direct_dependent_deps or something.

[dshwang, 2015-01-30 22:41:31]

On 2015/01/30 22:00:14, DaleCurtis wrote:
> Yeah, dependent modules shouldn't need to be modified, they should export a
> direct_dependent_deps or something.

mtklein and DaleCurtis, thx for good advice. Let me try

[dshwang, 2015-01-31 13:13:00]

On 2015/01/30 22:00:14, DaleCurtis wrote:
> Yeah, dependent modules shouldn't need to be modified, they should export a
> direct_dependent_deps or something.

could you give more tips?

I tried both export_dependent_settings and direct_dependent_settings as follows
but not work.
+++ b/media/media.gyp
@@ -74,6 +74,14 @@
       'defines': [
         'MEDIA_IMPLEMENTATION',
       ],
+      'export_dependent_settings': [
+        '../skia/skia.gyp:skia',
+      ],
+      'direct_dependent_settings': {
+        'dependencies': [
+          '../skia/skia.gyp:skia',
+        ],
+      },
       'include_dirs': [
         '..',
       ],

[DaleCurtis, 2015-02-02 18:55:35]

Can you upload the patch set? I can't tell which target you specified that on.
export_dependent_settings should work.

[dshwang, 2015-02-03 14:13:16]

On 2015/02/02 18:55:35, DaleCurtis wrote:
> Can you upload the patch set? I can't tell which target you specified that on.
> export_dependent_settings should work.

The target is media, because media_blink depends on media, which depends on
skia.

+++ b/media/media.gyp
@@ -74,6 +74,14 @@
  'targets': [
    {
      # GN version: //media
      'target_name': 'media',
      'type': '<(component)',
      'dependencies': [
...
        '../skia/skia.gyp:skia',
...
      ],
...
       'defines': [
         'MEDIA_IMPLEMENTATION',
       ],
+      'export_dependent_settings': [
+        '../skia/skia.gyp:skia',
+      ],
+      'direct_dependent_settings': {
+        'dependencies': [
+          '../skia/skia.gyp:skia',
+        ],
+      },
       'include_dirs': [
         '..',
       ],

According to GypUserDocumentation wiki, direct_dependent_settings can export
only defines, include_dirs, cflags and linkflags. IMO there is no way so that
indirect modules link to static library without explicit dependencies setting.
https://code.google.com/p/gyp/wiki/GypUserDocumentation
"""
'direct_dependent_settings': This defines the settings that will be applied to
other targets that directly depend on this target--that is, that list this
target in their 'dependencies' setting. This is where you list the defines,
include_dirs, cflags and linkflags that other targets that compile or link
against this target need to build consistently.

'export_dependent_settings': This lists the targets whose
direct_dependent_settings should be "passed on" to other targets that use
(depend on) this target. TODO: expand on this description.
"""

[DaleCurtis, 2015-02-03 18:53:26]

Interesting, I always thought deps propagated too. Do you know which header file
is causing this to be pulled in? Is there an include we should move into a .cc
file?

[dshwang, 2015-02-03 20:53:16]

On 2015/02/03 18:53:26, DaleCurtis wrote:
> Interesting, I always thought deps propagated too. Do you know which header
file
> is causing this to be pulled in? Is there an include we should move into a .cc
> file?

That's good point, but I already tried and failed.
I thought SkBitmap.h in skcanvas_video_renderer.h is problem 
filters/skcanvas_video_renderer.h:#include
"third_party/skia/include/core/SkBitmap.h
So I remove it via forward declaration, but it doesn't resolve this issue.

I think there are some indirectly included skia headers because SkBitmap.h is
very common.

In addition, skia owners said all indirectly dependent modules must link to skia
static library in https://codereview.chromium.org/870023002/

[DaleCurtis, 2015-02-03 20:55:51]

Ah, thanks for the details; this lgtm then assuming the skia folk are happy.

[mtklein, 2015-02-03 21:00:10]

On 2015/02/03 20:55:51, DaleCurtis wrote:
> Ah, thanks for the details; this lgtm then assuming the skia folk are happy.

Is it crazy to use all_dependent_settings in the skia GYP to force all things
that depend on skia indirectly to also depend on it directly?  Something like

all_dependent_settings {
  dependencies: [ '../skia/skia.gyp:skia' ],
}

?

[dshwang, 2015-02-04 12:53:37]

On 2015/02/03 21:00:10, mtklein wrote:
> On 2015/02/03 20:55:51, DaleCurtis wrote:
> > Ah, thanks for the details; this lgtm then assuming the skia folk are happy.
> 
> Is it crazy to use all_dependent_settings in the skia GYP to force all things
> that depend on skia indirectly to also depend on it directly?  Something like
> 
> all_dependent_settings {
>   dependencies: [ '../skia/skia.gyp:skia' ],
> }
> 
> ?

That's good point.
I also tried all_dependent_settings and failed. The log is as follows:
  File "/home/dshwang/chromium/src/tools/gyp/pylib/gyp/generator/ninja.py", line
2383, in GenerateOutput
    pool.map(CallGenerateOutputForConfig, arglists)
  KeyError: '../skia/skia.gyp:skia'

I think the difference between all_dependent_settings and
direct_dependent_settings is indirectly or directly applied separately.
That means the list is available is same such as defines, include_dirs, cflags
and linkflags.

[dshwang, 2015-02-04 12:54:25]

The CQ bit was checked by dongseong.hwang@intel.com

[commit-bot: I haz the power, 2015-02-04 12:55:21]

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

[commit-bot: I haz the power, 2015-02-04 13:30:58]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-02-04 13:33:18]

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