Move optional.h to webrtc/api/

Move optional.h to webrtc/api/

We use Optional in our public API, so its header should be in
webrtc/api/.

BUG=webrtc:8205
Review-Url: https://codereview.webrtc.org/3011943002
Cr-Commit-Position: refs/heads/master@{#19693}
Committed: https://chromium.googlesource.com/external/webrtc/+/84f6a3fc6b7759e98889a38ab74980efbf418ce7

[kwiberg-webrtc, 2017-09-05 11:11:29]

The CQ bit was checked by kwiberg@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2017-09-05 11:11:40]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2017-09-05 11:14:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-09-05 11:14:30]

Dry run: Try jobs failed on following builders:
  ios32_sim_ios9_dbg on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios32_sim_ios9_dbg/buil...)
  ios_arm64_dbg on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_dbg/builds/23648)
  ios_dbg on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_dbg/builds/28960)
  ios_rel on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_rel/builds/27982)

[kwiberg-webrtc, 2017-09-05 12:13:10]

The CQ bit was checked by kwiberg@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2017-09-05 12:13:19]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[kwiberg-webrtc, 2017-09-05 12:28:07]

Patchset #1 (id:1) has been deleted

[kwiberg-webrtc, 2017-09-05 12:28:27]

Patchset #1 (id:20001) has been deleted

[kwiberg-webrtc, 2017-09-05 12:40:11]

kwiberg@webrtc.org changed reviewers:
+ mbonadei@webrtc.org, nisse@webrtc.org

[mbonadei, 2017-09-05 12:45:47]

On 2017/09/05 12:40:13, kwiberg-webrtc wrote:

lgtm

[mbonadei, 2017-09-05 12:47:25]

The failure on mac_chromium_rel_ng seems unrelated.

[nisse-webrtc, 2017-09-05 13:03:24]

Have we discussed how fine grained build targets we want?

It might be overkill to split the public pieces of rtc_base into a single target
for each pair of .h and .cc, but perhaps it's the right way?

[mbonadei, 2017-09-05 13:22:58]

On 2017/09/05 13:03:24, nisse-webrtc wrote:
> Have we discussed how fine grained build targets we want?
> 
> It might be overkill to split the public pieces of rtc_base into a single
target
> for each pair of .h and .cc, but perhaps it's the right way?

I don't have a strong opinion. I can understand that the idea of creating a
target
for each pair of .h and .cc can be overkill but on the other side you get a lean
dependency tree because you only include what you need.

Maybe we can add an umbrella target later (if needed) to allow customers to
depend
on a smaller set of targets.

[kwiberg-webrtc, 2017-09-05 13:31:55]

On 2017/09/05 13:22:58, mbonadei wrote:
> On 2017/09/05 13:03:24, nisse-webrtc wrote:
> > Have we discussed how fine grained build targets we want?
> > 
> > It might be overkill to split the public pieces of rtc_base into a single
> target
> > for each pair of .h and .cc, but perhaps it's the right way?
> 
> I don't have a strong opinion. I can understand that the idea of creating a
> target
> for each pair of .h and .cc can be overkill but on the other side you get a
lean
> dependency tree because you only include what you need.
> 
> Maybe we can add an umbrella target later (if needed) to allow customers to
> depend
> on a smaller set of targets.

No, I don't recall discussing that.

I chose tiny build targets because (1) it makes for a lean dependency tree, and
(2) there's only one way to do it, whereas if we tried grouping into bigger
targets, there are countless ways to choose what gets grouped with what. And
although the number of build targets may grow large eventually, it's not large
yet; by the time it has grown large, we may have a better sense of what groups
to create, if any. We will then also have a better sense of the downsides of
creating many small build targets.

Does this sound reasonable?

[commit-bot: I haz the power, 2017-09-05 14:05:49]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-09-05 14:05:50]

Dry run: This issue passed the CQ dry run.

[mbonadei, 2017-09-05 14:18:36]

On 2017/09/05 13:31:55, kwiberg-webrtc wrote:
> On 2017/09/05 13:22:58, mbonadei wrote:
> > On 2017/09/05 13:03:24, nisse-webrtc wrote:
> > > Have we discussed how fine grained build targets we want?
> > > 
> > > It might be overkill to split the public pieces of rtc_base into a single
> > target
> > > for each pair of .h and .cc, but perhaps it's the right way?
> > 
> > I don't have a strong opinion. I can understand that the idea of creating a
> > target
> > for each pair of .h and .cc can be overkill but on the other side you get a
> lean
> > dependency tree because you only include what you need.
> > 
> > Maybe we can add an umbrella target later (if needed) to allow customers to
> > depend
> > on a smaller set of targets.
> 
> No, I don't recall discussing that.
> 
> I chose tiny build targets because (1) it makes for a lean dependency tree,
and
> (2) there's only one way to do it, whereas if we tried grouping into bigger
> targets, there are countless ways to choose what gets grouped with what. And
> although the number of build targets may grow large eventually, it's not large
> yet; by the time it has grown large, we may have a better sense of what groups
> to create, if any. We will then also have a better sense of the downsides of
> creating many small build targets.
> 
> Does this sound reasonable?

Yes it does. +1

[nisse-webrtc, 2017-09-05 14:26:35]

On 2017/09/05 14:18:36, mbonadei wrote:
> On 2017/09/05 13:31:55, kwiberg-webrtc wrote:
> > On 2017/09/05 13:22:58, mbonadei wrote:
> > > On 2017/09/05 13:03:24, nisse-webrtc wrote:
> > > > Have we discussed how fine grained build targets we want?
> > > > 
> > > > It might be overkill to split the public pieces of rtc_base into a
single
> > > target
> > > > for each pair of .h and .cc, but perhaps it's the right way?
> > > 
> > > I don't have a strong opinion. I can understand that the idea of creating
a
> > > target
> > > for each pair of .h and .cc can be overkill but on the other side you get
a
> > lean
> > > dependency tree because you only include what you need.
> > > 
> > > Maybe we can add an umbrella target later (if needed) to allow customers
to
> > > depend
> > > on a smaller set of targets.
> > 
> > No, I don't recall discussing that.
> > 
> > I chose tiny build targets because (1) it makes for a lean dependency tree,
> and
> > (2) there's only one way to do it, whereas if we tried grouping into bigger
> > targets, there are countless ways to choose what gets grouped with what. And
> > although the number of build targets may grow large eventually, it's not
large
> > yet; by the time it has grown large, we may have a better sense of what
groups
> > to create, if any. We will then also have a better sense of the downsides of
> > creating many small build targets.
> > 
> > Does this sound reasonable?
> 
> Yes it does. +1

lgtm. I guess we will have to create groups when we move rtc_base stuff with
circular dependencies.

[kwiberg-webrtc, 2017-09-05 15:33:26]

The CQ bit was checked by kwiberg@webrtc.org

[commit-bot: I haz the power, 2017-09-05 15:33:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-09-05 15:33:31]

This CL has an open dependency (Issue 3008143002 Patch 1). Please resolve the
dependency and try again.
If you are sure that there is no real dependency, please use one of the options
listed in https://goo.gl/9Es4OR to land the CL.

[kwiberg-webrtc, 2017-09-05 15:34:14]

On 2017/09/05 14:26:35, nisse-webrtc wrote:
> On 2017/09/05 14:18:36, mbonadei wrote:
> > On 2017/09/05 13:31:55, kwiberg-webrtc wrote:
> > > On 2017/09/05 13:22:58, mbonadei wrote:
> > > > On 2017/09/05 13:03:24, nisse-webrtc wrote:
> > > > > Have we discussed how fine grained build targets we want?
> > > > > 
> > > > > It might be overkill to split the public pieces of rtc_base into a
> single
> > > > target
> > > > > for each pair of .h and .cc, but perhaps it's the right way?
> > > > 
> > > > I don't have a strong opinion. I can understand that the idea of
creating
> a
> > > > target
> > > > for each pair of .h and .cc can be overkill but on the other side you
get
> a
> > > lean
> > > > dependency tree because you only include what you need.
> > > > 
> > > > Maybe we can add an umbrella target later (if needed) to allow customers
> to
> > > > depend
> > > > on a smaller set of targets.
> > > 
> > > No, I don't recall discussing that.
> > > 
> > > I chose tiny build targets because (1) it makes for a lean dependency
tree,
> > and
> > > (2) there's only one way to do it, whereas if we tried grouping into
bigger
> > > targets, there are countless ways to choose what gets grouped with what.
And
> > > although the number of build targets may grow large eventually, it's not
> large
> > > yet; by the time it has grown large, we may have a better sense of what
> groups
> > > to create, if any. We will then also have a better sense of the downsides
of
> > > creating many small build targets.
> > > 
> > > Does this sound reasonable?
> > 
> > Yes it does. +1
> 
> lgtm. I guess we will have to create groups when we move rtc_base stuff with
> circular dependencies.

Or break the circular dependencies...

[kwiberg-webrtc, 2017-09-05 15:39:30]

The CQ bit was checked by kwiberg@webrtc.org

[commit-bot: I haz the power, 2017-09-05 15:39:41]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2017-09-05 15:43:15]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1504625970668460,
"parent_rev": "ad43d4b29e54a914eeb88e7bc26db2271c5742f5", "commit_rev":
"84f6a3fc6b7759e98889a38ab74980efbf418ce7"}

[commit-bot: I haz the power, 2017-09-05 15:43:20]

Description was changed from

==========
Move optional.h to webrtc/api/

We use Optional in our public API, so its header should be in
webrtc/api/.

BUG=webrtc:8205
==========

to

==========
Move optional.h to webrtc/api/

We use Optional in our public API, so its header should be in
webrtc/api/.

BUG=webrtc:8205

Review-Url: https://codereview.webrtc.org/3011943002
Cr-Commit-Position: refs/heads/master@{#19693}
Committed:
https://chromium.googlesource.com/external/webrtc/+/84f6a3fc6b7759e98889a38ab...
==========

[commit-bot: I haz the power, 2017-09-05 15:43:22]

Committed patchset #1 (id:40001) as
https://chromium.googlesource.com/external/webrtc/+/84f6a3fc6b7759e98889a38ab...