e5f4c6b8d2
This is a reland of 69241a93fb14f6527a26d5c94dde879013012d2a Fix: The problem was related to NO_MAIN_THREAD_WRAPPING, which affects https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/rtc_base/thread.cc;l=257-263;drc=7acc2d9fe3a6e3c4d8881d2bdfc9b8968a724cd5. The original CL didn't attach the definition of the macro NO_MAIN_THREAD_WRAPPING when building for Chromium (which doesn't have to be related to //rtc_base anymore but to //rtc_base:threading). Original change's description: > Refactor rtc_base build targets. > > The "//rtc_base:rtc_base" build target has historically been one of the > biggest targets in the WebRTC build. Big targets are the main source of > circular dependencies and non-API types leakage. > > This CL is a step forward into splitting "//rtc_base:rtc_base" into > smaller targets (as originally started in 2018). > > The only non-automated changes are (like re-wiring the build system): > * The creation of //rtc_base/async_resolver.{h,cc} which allows to > break a circular dependency (is has been extracted from > //rtc_base/net_helpers.{h,cc}). > * The creation of //rtc_base/internal/default_socket_server.{h,cc} to > break another circular dependency. > > Bug: webrtc:9987 > Change-Id: I0c8f5e7efe2c8fd8e6bffa0d6dd2dd494cf3df02 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196903 > Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#32941} Bug: webrtc:9987 Change-Id: I7cdf49d2aac8357f1f50f90010bf2c2f62fa19f6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202021 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33001}
How to write code in the api/ directory
Mostly, just follow the regular style guide, but:
- Note that
api/code is not exempt from the “.hand.ccfiles come in pairs” rule, so if you declare something inapi/path/to/foo.h, it should be defined inapi/path/to/foo.cc. - Headers in
api/should, if possible, not#includeheaders outsideapi/. It’s not always possible to avoid this, but be aware that it adds to a small mountain of technical debt that we’re trying to shrink. .ccfiles inapi/, on the other hand, are free to#includeheaders outsideapi/.
That is, the preferred way for api/ code to access non-api/ code is to call
it from a .cc file, so that users of our API headers won’t transitively
#include non-public headers.
For headers in api/ that need to refer to non-public types, forward
declarations are often a lesser evil than including non-public header files. The
usual rules still apply, though.
.cc files in api/ should preferably be kept reasonably small. If a
substantial implementation is needed, consider putting it with our non-public
code, and just call it from the api/ .cc file.