[iOS/Mac/GN] The framework_bundle template should not force dependencies to link it.

[iOS/Mac/GN] The framework_bundle template should not force dependencies to link it.

Several targets require a build-time dependency on a framework bundle, but not a
link-time one. This can be if the target is only using the framework for its
resources or if it dlopen()s it at run-time.

framework_bundle now adds another target (target_name+link) that can be used if
something wants a link-time dependency on the framework bundle. By default, only
a build-time dependency is created.

BUG=297668
R=sdefresne@chromium.org,brettw@chromium.org

Committed: https://crrev.com/152572b1ae44de42b011c667c1d8bf317810851e
Cr-Commit-Position: refs/heads/master@{#389528}

[Robert Sesek, 2016-04-21 18:50:42]

Patchset #2 (id:20001) has been deleted

[Robert Sesek, 2016-04-21 19:06:42]

Patchset #1 (id:1) has been deleted

[Robert Sesek, 2016-04-21 19:32:39]

Patchset #2 (id:60001) has been deleted

[Robert Sesek, 2016-04-21 19:32:46]

Patchset #2 (id:80001) has been deleted

[brettw, 2016-04-21 20:27:55]

lgtm

https://codereview.chromium.org/1910133002/diff/100001/build/config/ios/rules...
File build/config/ios/rules.gni (right):

https://codereview.chromium.org/1910133002/diff/100001/build/config/ios/rules...
build/config/ios/rules.gni:17: # are also supported by this template.
Can you carefully document the behavior here, listing the names of things you
would depend on and in what cases you would depend on them? Ideally this would
also have some background for non-iOS people like me about why one would need to
depend on this but not link to it.

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

https://codereview.chromium.org/1910133002/diff/100001/build/config/mac/rules...
build/config/mac/rules.gni:10: # By default, the bundle target this template
generates does not link the
This seems like it would work in the other place. I think it would be good to
give an explicit example.

[sdefresne, 2016-04-22 07:59:48]

https://codereview.chromium.org/1910133002/diff/100001/build/config/mac/rules...
File build/config/mac/rules.gni (left):

https://codereview.chromium.org/1910133002/diff/100001/build/config/mac/rules...
build/config/mac/rules.gni:84: cflags_objc = common_flags
I think we need -F in cflags_objc/cflags_objcc when we use a framework with
embedded headers (which happens on iOS with OCHamcrest and EarlGrey).

[Robert Sesek, 2016-04-22 15:27:07]

https://codereview.chromium.org/1910133002/diff/100001/build/config/ios/rules...
File build/config/ios/rules.gni (right):

https://codereview.chromium.org/1910133002/diff/100001/build/config/ios/rules...
build/config/ios/rules.gni:17: # are also supported by this template.
On 2016/04/21 20:27:55, brettw wrote:
> Can you carefully document the behavior here, listing the names of things you
> would depend on and in what cases you would depend on them? Ideally this would
> also have some background for non-iOS people like me about why one would need
to
> depend on this but not link to it.

I added this to the base framework_bundle docs since both Mac and iOS need to
refer to it (rather than copy/paste it both places).

https://codereview.chromium.org/1910133002/diff/100001/build/config/mac/rules...
File build/config/mac/rules.gni (left):

https://codereview.chromium.org/1910133002/diff/100001/build/config/mac/rules...
build/config/mac/rules.gni:84: cflags_objc = common_flags
On 2016/04/22 07:59:48, sdefresne wrote:
> I think we need -F in cflags_objc/cflags_objcc when we use a framework with
> embedded headers (which happens on iOS with OCHamcrest and EarlGrey).

I moved that to the ios/rules.gni config since Mac doesn't ever use embedded
headers.

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

https://codereview.chromium.org/1910133002/diff/100001/build/config/mac/rules...
build/config/mac/rules.gni:10: # By default, the bundle target this template
generates does not link the
On 2016/04/21 20:27:55, brettw wrote:
> This seems like it would work in the other place. I think it would be good to
> give an explicit example.

Done.

[Robert Sesek, 2016-04-25 14:57:18]

sdefresne: PTAL

[sdefresne, 2016-04-25 16:47:53]

lgtm

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

https://codereview.chromium.org/1910133002/diff/120001/build/config/mac/rules...
build/config/mac/rules.gni:87: # Note that the framework is sitll copied to the
app's bundle, but dyld will
nit: sitll -> still

https://codereview.chromium.org/1910133002/diff/120001/build/config/mac/rules...
build/config/mac/rules.gni:91: # See "gn help shared_library" for more
information on arguments supported
nit: can you add an empty comment line to separate both paragraphs

[Robert Sesek, 2016-04-25 17:47:45]

Thanks!

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

https://codereview.chromium.org/1910133002/diff/120001/build/config/mac/rules...
build/config/mac/rules.gni:87: # Note that the framework is sitll copied to the
app's bundle, but dyld will
On 2016/04/25 16:47:52, sdefresne wrote:
> nit: sitll -> still

Done.

https://codereview.chromium.org/1910133002/diff/120001/build/config/mac/rules...
build/config/mac/rules.gni:91: # See "gn help shared_library" for more
information on arguments supported
On 2016/04/25 16:47:52, sdefresne wrote:
> nit: can you add an empty comment line to separate both paragraphs

Done.

[Robert Sesek, 2016-04-25 18:02:31]

The CQ bit was checked by rsesek@chromium.org

[Robert Sesek, 2016-04-25 18:02:32]

The patchset sent to the CQ was uploaded after l-g-t-m from brettw@chromium.org,
sdefresne@chromium.org
Link to the patchset: https://codereview.chromium.org/1910133002/#ps160001
(title: "Rebase")

[commit-bot: I haz the power, 2016-04-25 18:02:50]

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

[commit-bot: I haz the power, 2016-04-25 18:53:26]

Committed patchset #5 (id:160001)

[commit-bot: I haz the power, 2016-04-25 18:54:29]

Description was changed from

==========
[iOS/Mac/GN] The framework_bundle template should not force dependencies to link
it.

Several targets require a build-time dependency on a framework bundle, but not a
link-time one. This can be if the target is only using the framework for its
resources or if it dlopen()s it at run-time.

framework_bundle now adds another target (target_name+link) that can be used if
something wants a link-time dependency on the framework bundle. By default, only
a build-time dependency is created.

BUG=297668
R=sdefresne@chromium.org,brettw@chromium.org
==========

to

==========
[iOS/Mac/GN] The framework_bundle template should not force dependencies to link
it.

Several targets require a build-time dependency on a framework bundle, but not a
link-time one. This can be if the target is only using the framework for its
resources or if it dlopen()s it at run-time.

framework_bundle now adds another target (target_name+link) that can be used if
something wants a link-time dependency on the framework bundle. By default, only
a build-time dependency is created.

BUG=297668
R=sdefresne@chromium.org,brettw@chromium.org

Committed: https://crrev.com/152572b1ae44de42b011c667c1d8bf317810851e
Cr-Commit-Position: refs/heads/master@{#389528}
==========

[commit-bot: I haz the power, 2016-04-25 18:54:30]

Patchset 5 (id:??) landed as
https://crrev.com/152572b1ae44de42b011c667c1d8bf317810851e
Cr-Commit-Position: refs/heads/master@{#389528}