Add content_renderer and content_gpu to the dependency list of content_browser

Add content_renderer and content_gpu to the dependency list of content_browser

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

[Dirk Pranke, 2013-01-15 23:00:12]

lgtm.

john, it looks like content_browser grew some dependencies on _gpu and
_renderer, which we don't normally notice because of the way things are built. I
don't know how much you care about this, but you might want to look into the
dependencies at some point and fix them. In the meantime, you'll need this
change for Kai's stuff to work properly. Kai, perhaps you should file a bug to
track these dependencies, and dump a list of the needed symbols in that bug?

[kaiwang, 2013-01-15 23:31:57]

added link error to the bug

[jam, 2013-01-15 23:38:54]

On 2013/01/15 23:00:12, Dirk Pranke wrote:
> john, it looks like content_browser grew some dependencies on _gpu and
> _renderer, which we don't normally notice because of the way things are built.
I
> don't know how much you care about this, but you might want to look into the
> dependencies at some point and fix them. In the meantime, you'll need this
> change for Kai's stuff to work properly. Kai, perhaps you should file a bug to
> track these dependencies, and dump a list of the needed symbols in that bug?

i think these always existed, i.e. for in-process-renderer case and for gpu info
collector (see content\browser\DEPS and content\browser\renderer_host\DEPS)

can you explain more why we need these listed now?

[Dirk Pranke, 2013-01-15 23:48:09]

On 2013/01/15 23:38:54, John Abd-El-Malek wrote:
> On 2013/01/15 23:00:12, Dirk Pranke wrote:
> > john, it looks like content_browser grew some dependencies on _gpu and
> > _renderer, which we don't normally notice because of the way things are
built.
> I
> > don't know how much you care about this, but you might want to look into the
> > dependencies at some point and fix them. In the meantime, you'll need this
> > change for Kai's stuff to work properly. Kai, perhaps you should file a bug
to
> > track these dependencies, and dump a list of the needed symbols in that bug?
> 
> i think these always existed, i.e. for in-process-renderer case and for gpu
info
> collector (see content\browser\DEPS and content\browser\renderer_host\DEPS)
> 
> can you explain more why we need these listed now?

I'm guessing that components_unittest is perhaps the first place where we're
trying to build a binary (dll or executable) that only depends on part of
content? What is happening is that components_unittest is (correctly) declaring
only a dependency on content_browser, which in the static build / release
scenario is a static library that has undeclared dependencies on
content_renderer and content_gpu.

I think in the other cases (chrome_dll, content_unittests), the targets probably
depend on both content_browser and content_renderer, and so we've never noticed
the missing dependencies. Presumably this will be true for component_unittests
sooner or later as well, but isn't now. Make sense?

[jam, 2013-01-16 02:50:54]

On 2013/01/15 23:48:09, Dirk Pranke wrote:
> On 2013/01/15 23:38:54, John Abd-El-Malek wrote:
> > On 2013/01/15 23:00:12, Dirk Pranke wrote:
> > > john, it looks like content_browser grew some dependencies on _gpu and
> > > _renderer, which we don't normally notice because of the way things are
> built.
> > I
> > > don't know how much you care about this, but you might want to look into
the
> > > dependencies at some point and fix them. In the meantime, you'll need this
> > > change for Kai's stuff to work properly. Kai, perhaps you should file a
bug
> to
> > > track these dependencies, and dump a list of the needed symbols in that
bug?
> > 
> > i think these always existed, i.e. for in-process-renderer case and for gpu
> info
> > collector (see content\browser\DEPS and content\browser\renderer_host\DEPS)
> > 
> > can you explain more why we need these listed now?
> 
> I'm guessing that components_unittest is perhaps the first place where we're
> trying to build a binary (dll or executable) that only depends on part of
> content? What is happening is that components_unittest is (correctly)
declaring
> only a dependency on content_browser, which in the static build / release
> scenario is a static library that has undeclared dependencies on
> content_renderer and content_gpu.
> 
> I think in the other cases (chrome_dll, content_unittests), the targets
probably
> depend on both content_browser and content_renderer, and so we've never
noticed
> the missing dependencies. Presumably this will be true for component_unittests
> sooner or later as well, but isn't now. Make sense?

ah, that makes sense, thanks. lgtm

[commit-bot: I haz the power, 2013-01-16 03:39:59]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kaiwang@chromium.org/11948003/1

[commit-bot: I haz the power, 2013-01-16 03:55:46]

Retried try job too often on ios_dbg_simulator for step(s) base_unittests,
compile, content_unittests, crypto_unittests, googleurl_unittests,
media_unittests, net_unittests, sql_unittests, ui_unittests

[commit-bot: I haz the power, 2013-01-16 04:27:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kaiwang@chromium.org/11948003/11002

[commit-bot: I haz the power, 2013-01-16 09:13:00]

Change committed as 177113