[iOS/OSX/GN] Add -install_name to the shared_library ldflags on iOS.

[iOS/GN] Add -install_name to the shared_library ldflags on iOS.

The generated dylib will be available to the application via the
framework bundle so add "-install_name @rpath/XXX.framework/XXX"
when using the "ios_framework_bundle" template.

BUG=599321, 599322
Committed: https://crrev.com/598d2cbd50dee2c81201c10f662a74c7dd7dec18
Cr-Commit-Position: refs/heads/master@{#387273}

[sdefresne, 2016-04-13 11:59:46]

sdefresne@chromium.org changed reviewers:
+ rsesek@chromium.org

[sdefresne, 2016-04-13 11:59:46]

Please take a look.

[Robert Sesek, 2016-04-13 15:30:58]

https://codereview.chromium.org/1882423002/diff/1/build/config/mac/rules.gni
File build/config/mac/rules.gni (right):

https://codereview.chromium.org/1882423002/diff/1/build/config/mac/rules.gni#...
build/config/mac/rules.gni:60: "@rpath/$_framework_name/$_output_name",
This isn't going to be correct in all cases, and definitely not for Content
Shell Framework and Chromium Framework. This should become a template argument
if we go this route.

However I'm hoping that if we can change the output directory for targets (per
"[gn-dev] Location of intermediate library outputs in bundles"), then we can
keep the output_extension and output_prefix_override settings, not set any
ldflags here, and then the target can have complete control over ldflags.

Also, this needs to handle the case where the shared_library target has also set
ldflags (which it will do in some cases for the component build).

[sdefresne, 2016-04-13 16:20:38]

Description was changed from

==========
[iOS/OSX/GN] Add -install_name to the shared_library ldflags.

The generated dylib will be available to the application via the
framework bundle so add "-install_name @rpath/XXX.framework/XXX"
to the linker flag instead of overriding output name to remove
prefix and extension.

This fixes the collision that happens between the implicit target
generated from rule creating $root_out_dir/XXX and the explicit
target defined by {ios,mac}_framework_bundle("XXX").

Rename //ios/third_party/{earl_grey,ochamcrest} targets to their
output_name now that the underlying bug preventing this is fixed.

BUG=297668,599321,599322
==========

to

==========
[iOS/GN] Add -install_name to the shared_library ldflags.

The generated dylib will be available to the application via the
framework bundle so add "-install_name @rpath/XXX.framework/XXX".

BUG=599321,599322
==========

[sdefresne, 2016-04-13 16:28:43]

PTAL

https://codereview.chromium.org/1882423002/diff/1/build/config/mac/rules.gni
File build/config/mac/rules.gni (right):

https://codereview.chromium.org/1882423002/diff/1/build/config/mac/rules.gni#...
build/config/mac/rules.gni:60: "@rpath/$_framework_name/$_output_name",
On 2016/04/13 at 15:30:58, Robert Sesek wrote:
> This isn't going to be correct in all cases, and definitely not for Content
Shell Framework and Chromium Framework. This should become a template argument
if we go this route.
> 
> However I'm hoping that if we can change the output directory for targets (per
"[gn-dev] Location of intermediate library outputs in bundles"), then we can
keep the output_extension and output_prefix_override settings, not set any
ldflags here, and then the target can have complete control over ldflags.
> 
> Also, this needs to handle the case where the shared_library target has also
set ldflags (which it will do in some cases for the component build).

OK. This appears to be required for iOS (at least gyp does it for EarlGrey and
OCHamcrest). I've moved it out of this template and to ios_framework_bundle when
public_headers is not empty where it should always be correct (as iOS does not
support component build).

[Robert Sesek, 2016-04-13 18:15:22]

LGTM. install_name may still be a good argument to add to the template, but
we'll cross that bridge if/when we come to it.

[Robert Sesek, 2016-04-13 18:15:34]

Also update CL description to only target iOS

[sdefresne, 2016-04-14 09:09:03]

Description was changed from

==========
[iOS/GN] Add -install_name to the shared_library ldflags.

The generated dylib will be available to the application via the
framework bundle so add "-install_name @rpath/XXX.framework/XXX".

BUG=599321,599322
==========

to

==========
[iOS/GN] Add -install_name to the shared_library ldflags on iOS.

The generated dylib will be available to the application via the
framework bundle so add "-install_name @rpath/XXX.framework/XXX"
when using the "ios_framework_bundle" template.

BUG=599321,599322
==========

[sdefresne, 2016-04-14 09:09:07]

The CQ bit was checked by sdefresne@chromium.org

[commit-bot: I haz the power, 2016-04-14 09:09:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1882423002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1882423002/20001

[commit-bot: I haz the power, 2016-04-14 09:46:33]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-04-14 09:48:11]

Description was changed from

==========
[iOS/GN] Add -install_name to the shared_library ldflags on iOS.

The generated dylib will be available to the application via the
framework bundle so add "-install_name @rpath/XXX.framework/XXX"
when using the "ios_framework_bundle" template.

BUG=599321,599322
==========

to

==========
[iOS/GN] Add -install_name to the shared_library ldflags on iOS.

The generated dylib will be available to the application via the
framework bundle so add "-install_name @rpath/XXX.framework/XXX"
when using the "ios_framework_bundle" template.

BUG=599321,599322

Committed: https://crrev.com/598d2cbd50dee2c81201c10f662a74c7dd7dec18
Cr-Commit-Position: refs/heads/master@{#387273}
==========

[commit-bot: I haz the power, 2016-04-14 09:48:12]

Patchset 2 (id:??) landed as
https://crrev.com/598d2cbd50dee2c81201c10f662a74c7dd7dec18
Cr-Commit-Position: refs/heads/master@{#387273}