Allow external TaskQueue implementations on Linux

webrtc/pc/BUILD.gn

Index: webrtc/pc/BUILD.gn
diff --git a/webrtc/pc/BUILD.gn b/webrtc/pc/BUILD.gn
index 71e29d8a6cc4abc0199ea7a89c2eb61c0a073444..2ed020232e2364e61b7818f975f60fca3fb718cf 100644
--- a/webrtc/pc/BUILD.gn
+++ b/webrtc/pc/BUILD.gn
@@ -226,6 +226,12 @@ rtc_source_set("libjingle_peerconnection") {
     "../api:libjingle_peerconnection_api",
   ]
 
+  # This target always link with a default implementation
+  # regardless of the flag |rtc_link_task_queue_impl|.

[nisse-webrtc, 2017/08/23 11:00:25]

Why? It's not a test target, right?

[perkj_webrtc, 2017/08/23 11:12:37]

To not have to update all projects that depend on this. We can add a new target
don't have this deps if we want.

[nisse-webrtc, 2017/08/23 11:24:46]

Ok, we can refine it later. As far as I understand, we should have an
unconditional dependency for targets that build tests and our own example apps,
but not for library targets intended to be used by external applications.

[kwiberg-webrtc, 2017/08/23 13:23:25]

Hmm. I wonder if a gn variable (rtc_link_task_queue_impl) is too coarse-grained?
It will force the same setting on all build targets---or workarounds like this
one, which make the meaning of the gn variable unpleasantly complex.

Is it fair to say that what we want long-term is for our test binaries to
unconditionally link with the default TQ implementation, and for the library
(this target?) to unconditionally *not* link with the default TQ implementation?
*All* users of the library target would then have to manually link with their
preferred TQ implementation.

For the shorter term, we might have a gn flag that says whether the library
should link with the default TQ implementation. First this would default to
true, then to false, and finally we can remove it completely.

[nisse-webrtc, 2017/08/23 14:16:01]

For an application, it makes sense to have a single webrtc "thing" to link with,
be that a gn target, or a shared or static library, to get everything needed to
use webrtc. That target/library ought to include the default tq. And if it's a
important use case to have all of webrtc except the default task queue, a flag
doing just that could make sense.

Then, in addition, we'll want more fine-grained targets too, to let applications
grab only the building blocks they need. These fine-grained targets shouldn't
depend on the task_queue implementation.

gn doesn't have any notion of alternatives or weak dependencies? Ideally, it
would be nice to express to gn that a piece of code needs some task queue
implementation, with a weak dependency on the default implementation, meaning
that if none of the regular transitive dependencies for a top-level target
brings in any task queue implementation, the default should be linked in.

[perkj_webrtc, 2017/08/25 10:09:38]

It turns out that we don't need this exception. The flag can just mean, link or
not link. 

+  deps = [
+    "../rtc_base:rtc_task_queue_impl",
+  ]
+
   if (rtc_use_quic) {
     sources += [
       "quicdatachannel.cc",