Revert 175073 because it fails to compile on Linux.

Revert 175073 because it fails to compile on Linux.

http://build.chromium.org/p/chromium.linux/buildstatus?builder=Linux%20Builder%20x64&number=65699

> [Media Gallery] Move chrome/browser/media_transfer_protocol code to src/device.
> 
> BUG=156929
> TEST=none
> 
> 
> Review URL: https://chromiumcodereview.appspot.com/11744014

TBR=kmadhusu@chromium.org
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=175075

[Ryan Sleevi, 2013-01-04 01:51:45]

https://codereview.chromium.org/11722025/diff/1/device/device.gyp
File device/device.gyp (left):

https://codereview.chromium.org/11722025/diff/1/device/device.gyp#oldcode192
device/device.gyp:192: ],
The root issue for the failure is here. static_library targets are allowed to
concurrently build, unless they're marked hard_dependency OR one of their
dependencies has exported a dependency (export_dependent_settings) on a
hard_dependency.

You have two solutions, depending on how you want your "public" API to be:
1) export_dependent_settings the two _proto targets here. This is primarily
intended when one of YOUR public headers (_manager.h, _daemon_client.h) include
the .pb.h
2) In all targets that directly #include the .pb.h , add dependencies to the
_proto targets

I believe that in this case, #2 is more correct, and the dependency should be
expressed in chrome/chrome_browser.gypi, since those are the files that are
directly including those targets. We try to keep the dependencies close to their
targets, rather than by spooky-action-at-a-distance. That way, it's clear
if/when the dependencies can be removed, whereas export_dependent_settings-ing
it, it won't be clear if and when the dependency on the _protos can be removed.

[Ryan Sleevi, 2013-01-04 01:53:01]

Note: The failure was not that it strictly fails compiling - instead, it creates
build-timing races that will sporadically fail.

[kmadhusu, 2013-01-04 01:59:43]

On 2013/01/04 01:53:01, Ryan Sleevi wrote:
> Note: The failure was not that it strictly fails compiling - instead, it
creates
> build-timing races that will sporadically fail.

rsleevi@: Thanks for the explanation. Race condition explains why this CL didn't
fail in the try jobs.