Force load the Xcode arc libraries when building with llvm-build.

Force load the Xcode arc libraries when building with llvm-build.

It is necessary to force load libarclite from Xcode for
third_party/llvm-build because libarclite_* is only
distributed by Xcode.

BUG=None

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=201917

[justincohen, 2013-05-21 17:19:06]

What do you think?

[Nico, 2013-05-21 18:02:37]

Maybe this should be keyed on clang==1 instead of on the generator, as ninja
should be able to call the same clang binary that xcode calls?

https://codereview.chromium.org/15570002/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/15570002/diff/1/build/common.gypi#newcode4047
build/common.gypi:4047: ],
Does 'CLANG_ENABLE_OBJC_ARC': 'YES' work too? If so, that's maybe nicer.

https://codereview.chromium.org/15570002/diff/1/build/common.gypi#newcode4074
build/common.gypi:4074: '-force_load
<(arc_toolchain_path)/libarclite_iphoneos.a',
Make this two flags ('-force_load', '<arc_too…')

[justincohen, 2013-05-21 19:56:20]

Changed it to clang==1, that seems more correct to me.  Kept the -fobjc_arc,
though, since we only want the linker changes.

PTAL!

https://codereview.chromium.org/15570002/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/15570002/diff/1/build/common.gypi#newcode4047
build/common.gypi:4047: ],
On 2013/05/21 18:02:37, Nico wrote:
> Does 'CLANG_ENABLE_OBJC_ARC': 'YES' work too? If so, that's maybe nicer.

Nope, CLANG_EANBLE_OBJC_ARC changes the way files are compiled, not just linked.
 We don't want that.

https://codereview.chromium.org/15570002/diff/1/build/common.gypi#newcode4074
build/common.gypi:4074: '-force_load
<(arc_toolchain_path)/libarclite_iphoneos.a',
On 2013/05/21 18:02:37, Nico wrote:
> Make this two flags ('-force_load', '<arc_too…')

Done.

[Nico, 2013-05-21 20:02:38]

lgtm, but some ios person should approve this too.

https://codereview.chromium.org/15570002/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/15570002/diff/1/build/common.gypi#newcode4047
build/common.gypi:4047: ],
On 2013/05/21 19:56:20, justincohen wrote:
> On 2013/05/21 18:02:37, Nico wrote:
> > Does 'CLANG_ENABLE_OBJC_ARC': 'YES' work too? If so, that's maybe nicer.
> 
> Nope, CLANG_EANBLE_OBJC_ARC changes the way files are compiled, not just
linked.
>  We don't want that.

Maybe add to your comment that you're intentionally not using
CLANG_ENABLE_OBJC_ARC then.

https://codereview.chromium.org/15570002/diff/8001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/15570002/diff/8001/build/common.gypi#newcode4047
build/common.gypi:4047: ],
Shouldn't this part be gated on clang!=1 too?

[justincohen, 2013-05-21 23:33:15]

https://codereview.chromium.org/15570002/diff/8001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/15570002/diff/8001/build/common.gypi#newcode4047
build/common.gypi:4047: ],
On 2013/05/21 20:02:38, Nico wrote:
> Shouldn't this part be gated on clang!=1 too?

I wonder if we will ever do iOS Xcode builds with thirdparty/llvm.  Either way,
thanks, I've updated it!

[Alexander Potapenko, 2013-05-22 08:53:43]

I confirm this patch fixes the ASan build for iOS simulator.
I've updated
https://sites.google.com/a/chromium.org/dev/developers/testing/addresssanitiz...

[stuartmorgan, 2013-05-22 09:06:12]

https://codereview.chromium.org/15570002/diff/19001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/15570002/diff/19001/build/common.gypi#newcode...
build/common.gypi:4075: ['target_arch=="armv7"', {
This section doesn't make sense for Xcode (target_arch is fluid at compile-time
for Xcode), so it should be gated on ninja.

[justincohen, 2013-05-22 13:50:52]

@stuart: done, ptal!

https://codereview.chromium.org/15570002/diff/19001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/15570002/diff/19001/build/common.gypi#newcode...
build/common.gypi:4075: ['target_arch=="armv7"', {
On 2013/05/22 09:06:13, stuartmorgan wrote:
> This section doesn't make sense for Xcode (target_arch is fluid at
compile-time
> for Xcode), so it should be gated on ninja.

Done.

[stuartmorgan, 2013-05-22 14:02:20]

https://codereview.chromium.org/15570002/diff/34001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/15570002/diff/34001/build/common.gypi#newcode...
build/common.gypi:4081: 'OTHER_LDFLAGS': [
Couldn't you do OTHER_LDFLAGS[arch=armv7] and [arch=x86] (or whatever the right
values are) so that both would work from Xcode?

[justincohen, 2013-05-22 16:42:25]

I didn't know Xcode handled [arch=].  I updated the gyp to handle this case,
although building Xcode with clang=1 is not currently supported.

PTAL!

[Nico, 2013-05-22 16:52:22]

Unrelated to this CL: All the other chrome ports expect the target arch to be
set at gyp time (even if you use make, which allows picking debug/release at
build time for example). Requiring this for xcode might make some things simpler
(and other more complicated I suppose).

On mac, we set target_arch at gyp time for 64bit builds too.

[stuartmorgan, 2013-05-23 12:41:43]

On 2013/05/22 16:52:22, Nico wrote:
> Requiring this for xcode might make some things simpler
> (and other more complicated I suppose).

This would make iOS development unlivable, IMO.

[stuartmorgan, 2013-05-23 12:43:56]

LGTM

[commit-bot: I haz the power, 2013-05-23 12:50:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/justincohen@google.com/15570002/38004

[commit-bot: I haz the power, 2013-05-23 23:05:06]

Change committed as 201917