Add files required to link with WebRTC for Chromium on iOS.

Add files required to link with WebRTC for Chromium on iOS.

When building webrtc for Chromium on iOS, rtc::InitCocoaMultiThreading is
called from rtc::ThreadManager::ThreadManager, so add the implementation
of that method when targetting iOS.

Fixes the following link error:

FAILED: ../../third_party/llvm-build/Release+Asserts/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.1.sdk -stdlib=libc++ -mios-simulator-version-min=7.0 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.1.sdk  -weak_framework WebKit -o "./components_unittests.app/components_unittests" -Wl,-filelist,"./components_unittests.app/components_unittests.rsp"  -framework UIKit -framework QuartzCore -framework OpenGLES -framework CoreFoundation -framework CoreGraphics -framework CoreText -framework Foundation -framework ImageIO -framework CFNetwork -framework MobileCoreServices -framework Security -framework SystemConfiguration -lresolv -lsqlite3 -lz
Undefined symbols for architecture x86_64:
  "rtc::InitCocoaMultiThreading()", referenced from:
      rtc::ThreadManager::ThreadManager() in librtc_base.a(thread.o)
ld: symbol(s) not found for architecture x86_64

BUG=551954

[sdefresne, 2015-11-16 14:05:45]

sdefresne@chromium.org changed reviewers:
+ kjellander@webrtc.org

[sdefresne, 2015-11-16 14:05:45]

Please take a look.

[kjellander_webrtc, 2015-11-16 14:56:31]

Unless necessary, please don't run all bots for a GN-only change (we're a bit
scarce on resources in WebRTC)

https://codereview.webrtc.org/1444323002/diff/1/webrtc/base/BUILD.gn
File webrtc/base/BUILD.gn (right):

https://codereview.webrtc.org/1444323002/diff/1/webrtc/base/BUILD.gn#newcode498
webrtc/base/BUILD.gn:498: "maccocoathreadhelper.h",
Can you update the base.gyp with the same change?

While you're at it, please change it from:
'sources/': [
  ['include', 'macconversion.*'],
],

to be:
'sources': [
  'maccocoathreadhelper.h',
  'maccocoathreadhelper.mm',
  'macconversion.cc',
  'macconversion.h',
],
to make it easier to compare the two.

[sdefresne, 2015-11-16 15:50:52]

On 2015/11/16 at 14:56:31, kjellander wrote:
> Unless necessary, please don't run all bots for a GN-only change (we're a bit
scarce on resources in WebRTC)
> 
> https://codereview.webrtc.org/1444323002/diff/1/webrtc/base/BUILD.gn
> File webrtc/base/BUILD.gn (right):
> 
>
https://codereview.webrtc.org/1444323002/diff/1/webrtc/base/BUILD.gn#newcode498
> webrtc/base/BUILD.gn:498: "maccocoathreadhelper.h",
> Can you update the base.gyp with the same change?
> 
> While you're at it, please change it from:
> 'sources/': [
>   ['include', 'macconversion.*'],
> ],
> 
> to be:
> 'sources': [
>   'maccocoathreadhelper.h',
>   'maccocoathreadhelper.mm',
>   'macconversion.cc',
>   'macconversion.h',
> ],
> to make it easier to compare the two.

I've used

'sources/': [
  ['include', 'maccocoathreadhelper.h'],
  ...
],

because AFAIK, 'sources' cannot bypass the global filter (only 'source/' can).

[sdefresne, 2015-11-16 15:51:07]

Could you take another look?

[kjellander_webrtc, 2015-11-16 17:46:35]

kjellander@webrtc.org changed reviewers:
+ henrika@webrtc.org

[kjellander_webrtc, 2015-11-16 17:46:35]

lgtm, but I'm adding henrika@ too since I don't know all the details about iOS.

[kjellander_webrtc, 2015-11-16 17:47:13]

On 2015/11/16 17:46:35, kjellander (webrtc) wrote:
> lgtm, but I'm adding henrika@ too since I don't know all the details about
iOS.

(ignore the iOS GN bot, it's not supposed to be working yet, which is part of
what you're helping out fixing here)

[henrika_webrtc, 2015-11-16 18:07:39]

Description was changed from

==========
Add files required to link with WebRTC for Chromium on iOS.

When building webrtc for Chromium on iOS, rtc::InitCocoaMultiThreading is
called from rtc::ThreadManager::ThreadManager, so add the implementation
of that method when targetting iOS.

Fixes the following link error:

FAILED: ../../third_party/llvm-build/Release+Asserts/bin/clang++ -arch x86_64
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.1.sdk
-stdlib=libc++ -mios-simulator-version-min=7.0
--sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.1.sdk
 -weak_framework WebKit -o "./components_unittests.app/components_unittests"
-Wl,-filelist,"./components_unittests.app/components_unittests.rsp"  -framework
UIKit -framework QuartzCore -framework OpenGLES -framework CoreFoundation
-framework CoreGraphics -framework CoreText -framework Foundation -framework
ImageIO -framework CFNetwork -framework MobileCoreServices -framework Security
-framework SystemConfiguration -lresolv -lsqlite3 -lz
Undefined symbols for architecture x86_64:
  "rtc::InitCocoaMultiThreading()", referenced from:
      rtc::ThreadManager::ThreadManager() in librtc_base.a(thread.o)
ld: symbol(s) not found for architecture x86_64

BUG=551954
==========

to

==========
Add files required to link with WebRTC for Chromium on iOS.

When building webrtc for Chromium on iOS, rtc::InitCocoaMultiThreading is
called from rtc::ThreadManager::ThreadManager, so add the implementation
of that method when targetting iOS.

Fixes the following link error:

FAILED: ../../third_party/llvm-build/Release+Asserts/bin/clang++ -arch x86_64
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.1.sdk
-stdlib=libc++ -mios-simulator-version-min=7.0
--sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.1.sdk
 -weak_framework WebKit -o "./components_unittests.app/components_unittests"
-Wl,-filelist,"./components_unittests.app/components_unittests.rsp"  -framework
UIKit -framework QuartzCore -framework OpenGLES -framework CoreFoundation
-framework CoreGraphics -framework CoreText -framework Foundation -framework
ImageIO -framework CFNetwork -framework MobileCoreServices -framework Security
-framework SystemConfiguration -lresolv -lsqlite3 -lz
Undefined symbols for architecture x86_64:
  "rtc::InitCocoaMultiThreading()", referenced from:
      rtc::ThreadManager::ThreadManager() in librtc_base.a(thread.o)
ld: symbol(s) not found for architecture x86_64

BUG=551954
==========

[henrika_webrtc, 2015-11-16 18:07:40]

henrika@webrtc.org changed reviewers:
+ tkchin@webrtc.org

[henrika_webrtc, 2015-11-16 18:09:55]

Sorry, not sure what the goal is here really. In short, I don't know enough
details to OK this CL. Adding tkchin.

[tkchin_webrtc, 2015-11-16 21:12:26]

On 2015/11/16 18:09:55, henrika_webrtc wrote:
> Sorry, not sure what the goal is here really. In short, I don't know enough
> details to OK this CL. Adding tkchin.

lgtm % bots (which I'm kicking off now)
Why are you building WebRTC for iOS chromium though? Afaik WebRTC isn't
supported in iOS chromium because of WebKit? Has that changed?

[henrika_webrtc, 2015-11-17 08:20:39]

And AFAIK, there is no media support in Chromium for iOS.
What WebRTC APIs shall be supported?

[sdefresne, 2015-11-17 09:05:05]

On 2015/11/17 at 08:20:39, henrika wrote:
> And AFAIK, there is no media support in Chromium for iOS.
> What WebRTC APIs shall be supported?

I'm building WebRTC because of
https://code.google.com/p/chromium/issues/detail?id=556433.

TL;DR: Chromium //components/autofill depends on WebRTC to use WebRTC xmllite.
This is unfortunate and tfarina@ and vabr@ are working on resolving this
dependency. Currently with gyp, all unused code ends up discarded at link time,
but with gn they ends up causing link failures.

[henrika_webrtc, 2015-11-17 09:19:56]

henrika@webrtc.org changed reviewers:
+ tommi@webrtc.org

[tommi, 2015-11-17 10:06:11]

Can you clarify exactly what it is that you're fixing?  What is being linked on
iOS and for what reasons?

If this is related to the XML dependency issue in Chromium bug 556433, then I'd
rather not commit this since that dependency addition is wrong.

Tagging as not lgtm for now to be sure.

[sdefresne, 2015-11-17 10:10:34]

On 2015/11/17 at 10:06:11, tommi wrote:
> Can you clarify exactly what it is that you're fixing?  What is being linked
on iOS and for what reasons?
> 
> If this is related to the XML dependency issue in Chromium bug 556433, then
I'd rather not commit this since that dependency addition is wrong.
> 
> Tagging as not lgtm for now to be sure.

I'm fixing the error that is inlined in the CL description.

rtc::ThreadManager::ThreadManager() calls rtc::InitCocoaMultiThreading(). The
method rtc::InitCocoaMultiThreading() is defined in maccocoathreadhelper.mm. If
this file is not build on iOS, then the library rtc_base is incomplete on iOS
cannot be linked. This does not manifest with gyp because the none of the client
of rtc_base calls rtc::ThreadManager and the code is dropped at link time,
however, with gn since static_set are used instead of static_library, no code is
dropped at link time.

This is independent of
https://code.google.com/p/chromium/issues/detail?id=556433 (in the sense that
there is a bug in rtc_base definition in webrtc/base/BUILD.gn that will stay
present unless fixed even if Chromium stops using WebRTC on iOS).

[kjellander_webrtc, 2015-11-23 14:31:52]

On 2015/11/17 10:10:34, sdefresne wrote:
> On 2015/11/17 at 10:06:11, tommi wrote:
> > Can you clarify exactly what it is that you're fixing?  What is being linked
> on iOS and for what reasons?
> > 
> > If this is related to the XML dependency issue in Chromium bug 556433, then
> I'd rather not commit this since that dependency addition is wrong.
> > 
> > Tagging as not lgtm for now to be sure.
> 
> I'm fixing the error that is inlined in the CL description.
> 
> rtc::ThreadManager::ThreadManager() calls rtc::InitCocoaMultiThreading(). The
> method rtc::InitCocoaMultiThreading() is defined in maccocoathreadhelper.mm.
If
> this file is not build on iOS, then the library rtc_base is incomplete on iOS
> cannot be linked. This does not manifest with gyp because the none of the
client
> of rtc_base calls rtc::ThreadManager and the code is dropped at link time,
> however, with gn since static_set are used instead of static_library, no code
is
> dropped at link time.
> 
> This is independent of
> https://code.google.com/p/chromium/issues/detail?id=556433 (in the sense that
> there is a bug in rtc_base definition in webrtc/base/BUILD.gn that will stay
> present unless fixed even if Chromium stops using WebRTC on iOS).

It seems to make sense to fix this if it's a problem, but how come we don't get
linking 
errors when building rtc_unittests (in webrtc/webrtc_tests.gypi) today in WebRTC
then? 
It depends on webrtc/base/base_tests.gyp:rtc_base_tests_utils which depends on
webrtc/base/base.gyp:rtc_base.

[sdefresne, 2015-11-23 14:39:43]

On 2015/11/23 at 14:31:52, kjellander wrote:
> On 2015/11/17 10:10:34, sdefresne wrote:
> > On 2015/11/17 at 10:06:11, tommi wrote:
> > > Can you clarify exactly what it is that you're fixing?  What is being
linked
> > on iOS and for what reasons?
> > > 
> > > If this is related to the XML dependency issue in Chromium bug 556433,
then
> > I'd rather not commit this since that dependency addition is wrong.
> > > 
> > > Tagging as not lgtm for now to be sure.
> > 
> > I'm fixing the error that is inlined in the CL description.
> > 
> > rtc::ThreadManager::ThreadManager() calls rtc::InitCocoaMultiThreading().
The
> > method rtc::InitCocoaMultiThreading() is defined in maccocoathreadhelper.mm.
If
> > this file is not build on iOS, then the library rtc_base is incomplete on
iOS
> > cannot be linked. This does not manifest with gyp because the none of the
client
> > of rtc_base calls rtc::ThreadManager and the code is dropped at link time,
> > however, with gn since static_set are used instead of static_library, no
code is
> > dropped at link time.
> > 
> > This is independent of
> > https://code.google.com/p/chromium/issues/detail?id=556433 (in the sense
that
> > there is a bug in rtc_base definition in webrtc/base/BUILD.gn that will stay
> > present unless fixed even if Chromium stops using WebRTC on iOS).
> 
> It seems to make sense to fix this if it's a problem, but how come we don't
get linking 
> errors when building rtc_unittests (in webrtc/webrtc_tests.gypi) today in
WebRTC then? 
> It depends on webrtc/base/base_tests.gyp:rtc_base_tests_utils which depends on
webrtc/base/base.gyp:rtc_base.

I've explained this in comment #14. Answer is

  Currently with gyp, all unused code ends up discarded at link time, but with
gn they ends up causing link failures.

TL;DR: gn uses source_set, gyp uses static_library. They do not behave the same
at link time. static_library allow dropping unused code, source_set do not.

[sdefresne, 2015-11-23 14:40:12]

On 2015/11/23 at 14:39:43, sdefresne wrote:
> On 2015/11/23 at 14:31:52, kjellander wrote:
> > On 2015/11/17 10:10:34, sdefresne wrote:
> > > On 2015/11/17 at 10:06:11, tommi wrote:
> > > > Can you clarify exactly what it is that you're fixing?  What is being
linked
> > > on iOS and for what reasons?
> > > > 
> > > > If this is related to the XML dependency issue in Chromium bug 556433,
then
> > > I'd rather not commit this since that dependency addition is wrong.
> > > > 
> > > > Tagging as not lgtm for now to be sure.
> > > 
> > > I'm fixing the error that is inlined in the CL description.
> > > 
> > > rtc::ThreadManager::ThreadManager() calls rtc::InitCocoaMultiThreading().
The
> > > method rtc::InitCocoaMultiThreading() is defined in
maccocoathreadhelper.mm. If
> > > this file is not build on iOS, then the library rtc_base is incomplete on
iOS
> > > cannot be linked. This does not manifest with gyp because the none of the
client
> > > of rtc_base calls rtc::ThreadManager and the code is dropped at link time,
> > > however, with gn since static_set are used instead of static_library, no
code is
> > > dropped at link time.
> > > 
> > > This is independent of
> > > https://code.google.com/p/chromium/issues/detail?id=556433 (in the sense
that
> > > there is a bug in rtc_base definition in webrtc/base/BUILD.gn that will
stay
> > > present unless fixed even if Chromium stops using WebRTC on iOS).
> > 
> > It seems to make sense to fix this if it's a problem, but how come we don't
get linking 
> > errors when building rtc_unittests (in webrtc/webrtc_tests.gypi) today in
WebRTC then? 
> > It depends on webrtc/base/base_tests.gyp:rtc_base_tests_utils which depends
on webrtc/base/base.gyp:rtc_base.
> 
> I've explained this in comment #14. Answer is
> 
>   Currently with gyp, all unused code ends up discarded at link time, but with
gn they ends up causing link failures.
> 
> TL;DR: gn uses source_set, gyp uses static_library. They do not behave the
same at link time. static_library allow dropping unused code, source_set do not.

You can use "gn help source_set" to get more information on that.