Move AudioDecoder and related stuff to the api/ directory

webrtc/api/audio_codec/BUILD.gn

+# Copyright (c) 2017 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) {
+  import("//build/config/android/config.gni")
+  import("//build/config/android/rules.gni")
+}
+
+rtc_source_set("audio_decoder_factory_interface") {

[kjellander_webrtc, 2017/02/01 14:54:50]

Can we use _api suffix instead? It's the most commonly used in webrtc/api (with
the exception for call_interfaces).

[ossu, 2017/02/01 15:05:26]

General stuff-in-api/ question:

Should we add _interface to the end of targets, or should it be _api or should
we leave them just without a suffix? I believe I like suffix-less best; like how
generally don't suffix class interfaces with Interface either. 

[kwiberg-webrtc, 2017/02/01 20:15:02]

The full name of an api/ build target "foo" is "webrtc/api:foo" (or
"webrtc/api/subdir:foo", if it's in a subdirectory). It seems redundant to add
an "_api" suffix or prefix on top of that.

"_interface" is at least somewhat useful, since not all api/ build targets are
interfaces. I don't really have an opinion there.

[the sun, 2017/02/02 21:02:28]

All good points, but let's stick to using the _api suffix as 
1) it is proposed in the design doc
2) already in use
3) distinguishing the source_set targets (which just provide the interface) from
the default implementations (which don't have any suffix) is a good thing.
4) it is shorter than _interface

[kwiberg-webrtc, 2017/02/03 09:50:11]

Ugh. I wish I'd noticed that in time...
Adding an _api suffix to all build targets won't accomplish that. Are you
suggesting that only one of source_set and static_library should have the
suffix? (And in that case, for what reason? As far as the target that depends on
them is concerned, there is no visible difference.)

[Looked at the design doc.] OK, so only the source_sets should end in _api.
Makes no sense to me, but I'll live with it rather than argue.
Yes, but that's irrelevant since no one was suggesting that as a suffix for all
build targets in api/. On the other hand, a point *against* the "_api" suffix is
that it's longer than the "" suffix...

But I'll add the suffix, in the interest of not letting an already painted bike
shed get in the way of progress.

+  sources = [
+    "audio_decoder_factory.h",
+  ]
+  deps = [

[ossu, 2017/02/01 15:05:26]

Next general question:

Where do we draw the line between deps and public_deps?
Naïvely, I'd say audio_decoder_interface and audio_format should be public_deps.
Actually, most stuff in api/ depending on other stuff in api/ should probably be
public? Or have I misunderstood?

[kwiberg-webrtc, 2017/02/01 20:15:02]

Hmm. That goes against my intuition (which is that if you want to #include a
header, you should depend on its build target---which means you never use
public_deps). I'll happily listen to arguments why I'm wrong, though.

[ossu, 2017/02/06 12:54:16]

I don't really know. I was hoping kjellander@ would have an answer to this, as
he's also reviewing this CL. I thought of as what, generally, is the difference
between deps and public_deps. Maybe I should read the friendly manual? :) Now
that you mention it, though, it's also a project-specific question.

I was under the impression that transitively included headers would require
adding deps, but if that's not the case, then you're probably right. What I was
thinking was: if we're going for many small targets, it quickly becomes a chore
to keep your deps up-to-date. In the audio_decoder_factory example,
audio_decoder and audio format are both parts of the public API of
audio_decoder_factory. You can't really use the factory without knowing about
those headers. For a big target, it might be different. If audio_coding were a
single target, then it should probably be self-contained and not pull in
anything else, possibly also large, publically.

[kwiberg-webrtc, 2017/02/06 14:19:36]

I'm really sure it's not---that would be madness. public_deps is used by targets
that want to export *other* targets' include files, IIUC; in other words, if you
want to take a bunch of smaller targets and logically bundle them together so
that they'll be easier to depend on, without actually merging them into one big
target, then make a new target that public_deps on all the targets whose headers
it should be re-exporting.
I discussed this with solenberg@, who had much the same objections. We decided
that I should follow his idea of making bigger targets for "light-weight" stuff
(i.e. stuff with transitively little or no .cc content) and continue to have
separate targets for "heavy-weight" stuff (i.e. stuff with transitively lots of
.cc content).

+    ":audio_decoder_interface",
+    ":audio_format",
+    "../../base:rtc_base_approved",
+  ]
+}
+
+rtc_static_library("audio_decoder_interface") {
+  sources = [
+    "audio_decoder.cc",
+    "audio_decoder.h",
+  ]
+  deps = [
+    "../..:webrtc_common",
+    "../../base:rtc_base_approved",
+  ]
+}
+
+rtc_static_library("audio_format") {
+  sources = [
+    "audio_format.cc",
+    "audio_format.h",
+  ]
+  deps = [
+    "../..:webrtc_common",
+  ]
+}
+
+rtc_static_library("builtin_audio_decoder_factory") {
+  sources = [
+    "builtin_audio_decoder_factory.cc",
+    "builtin_audio_decoder_factory.h",
+  ]
+  deps = [
+    ":audio_decoder_factory_interface",
+    "../../base:rtc_base_approved",
+    "../../modules/audio_coding:internal_builtin_audio_decoder_factory",
+  ]
+}