Allow external TaskQueue implementations on Linux

webrtc/pc/BUILD.gn

 # Copyright (c) 2016 The WebRTC project authors. All Rights Reserved.
 #
 # Use of this source code is governed by a BSD-style license
 # that can be found in the LICENSE file in the root of the source
 # tree. An additional intellectual property rights grant can be found
 # in the file PATENTS.  All contributing project authors may
 # be found in the AUTHORS file in the root of the source tree.
 
 import("../webrtc.gni")
 if (is_android) {
@@ skipping 208 matching lines @@
   }
 }
 
 rtc_source_set("libjingle_peerconnection") {
   public_deps = [
     ":create_pc_factory",
     ":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",
       "quicdatachannel.h",
       "quicdatatransport.cc",
       "quicdatatransport.h",
     ]
     deps += [ "//third_party/libquic" ]
     public_deps = [
       "//third_party/libquic",
@@ skipping 218 matching lines @@
       "//testing/gmock",
     ]
 
     if (is_android) {
       deps += [ "//testing/android/native_test:native_test_support" ]
 
       shard_timeout = 900
     }
   }
 }