GN Rule to build Cronet Dynamic Framework for iOS.

components/cronet/ios/BUILD.gn

Index: components/cronet/ios/BUILD.gn
diff --git a/components/cronet/ios/BUILD.gn b/components/cronet/ios/BUILD.gn
index 19ff7514cf2e3ed18404b4541d512bd9370e9519..2271903767f5c94411839a94f0d78454f8062cdc 100644
--- a/components/cronet/ios/BUILD.gn
+++ b/components/cronet/ios/BUILD.gn
@@ -4,6 +4,7 @@
 
 import("//build/buildflag_header.gni")
 import("//build/config/ios/rules.gni")
+import("//build/mac/tweak_info_plist.gni")
 import("//build/util/version.gni")
 import("//chrome/version.gni")
 import("//testing/test.gni")
@@ -53,17 +54,30 @@ source_set("cronet_sources") {
   }
 }
 
+# Tweak |info_plist| with current version and revision.
+tweak_info_plist("cronet_framework_plist") {
+  info_plist = "Info.plist"
+  args = [ "--bundle_id=CRNT" ]

[kapishnikov, 2016/06/30 21:59:55]

Usually bundle id has a domain-like structure. I would suggest
"org.chromium.net.Cronet".

[mef, 2016/07/01 14:10:08]

Done.

+}
+
+# Compile plist into |output_name|.
+ios_info_plist("cronet_info_plist") {
+  executable_name = "Cronet"
+
+  output_name = "$root_out_dir/Cronet.framework/Info.plist"

[mef, 2016/06/30 21:29:06]

Is there a way to avoid hardcoding output path?

[Robert Sesek, 2016/06/30 21:43:14]

It doesn't look like the ios_framework_bundle has an info_plist_target option
like ios_app_bundle or mac_framework_bundle do. That's the proper way to handle
this (via a bundle_data rule).

[mef, 2016/07/01 14:10:08]

I've followed Sylvain's suggestion, and it seemed to work WRT to avoiding to
hard-code path to upper target.

+  info_plist_target = ":cronet_framework_plist"
+}
+
 ios_framework_bundle("cronet_framework") {
   output_name = "Cronet"
 
   deps = [
+    ":cronet_info_plist",
     ":cronet_sources",
     "//base",
     "//net:net",
   ]
 
-  info_plist = "Info.plist"
-
   libs = [ "UIKit.Framework" ]
 
   public_headers = [
@@ -75,6 +89,18 @@ ios_framework_bundle("cronet_framework") {
     "Cronet.h",
     "Cronet.mm",
   ]
+
+  configs -= [ "//build/config/compiler:default_symbols" ]
+  configs += [ "//build/config/compiler:symbols" ]
+
+  ldflags =
+      [ "-Wl,-install_name,@loader_path/Frameworks/Cronet.framework/Cronet" ]
+
+  # For release version generate a separate dSYM.
+  if (!is_debug) {
+    ldflags += [ "-Wcrl,strip,-x" ]

[Robert Sesek, 2016/06/30 21:43:15]

Similarly, we handle stripping globally with enable_stripping=true and it gets
picked up via this config:
https://cs.chromium.org/chromium/src/build/config/mac/BUILD.gn?dr=C&sq=packag...

[mef, 2016/07/01 14:10:08]

If there is a better way via updating template, I'll be happy to do it.
I've tried, but I've failed with that though.

+    ldflags += [ "-Wcrl,dsym," + rebase_path(root_out_dir) ]

[mef, 2016/06/30 21:29:06]

Is there a way to specify that this outputs Cronet.dSYM?

[Robert Sesek, 2016/06/30 21:43:15]

On Mac at least, we handle dSYMs and stripping at the build configuration level.
One sets enable_dsyms = true and then the -Wcrl flag gets added by the toolchain
(https://cs.chromium.org/chromium/src/build/toolchain/mac/BUILD.gn?type=cs&sq=...).

[mef, 2016/07/01 14:10:08]

I've tried that, but it didn't work for ios_framework_bundle. I'd love to make
it work, but I may need some help.

[Robert Sesek, 2016/07/01 15:37:43]

Sorry if I wasn't being clear; these aren't arguments consumed by the template.
They are build-level `gn args` arguments. Stripping and dSYM production applies
to all targets in the build.

[mef, 2016/07/01 16:02:35]

That's very cool, I didn't realize that. I've tried adding enable_dsyms to gn
args, and it generated dsyms, however it didn't add Cronet.dSYM to the set of
outputs, so line 183 below still fails with 'no target that generates this
source'.

I've also tried to specify 'enable_stripping = true' but that didn't seem to
have any effect. Any ideas?

[Robert Sesek, 2016/07/01 16:50:28]

Hmm, I guess I worked around the dSYM output issue in the one instance where it
came up:
https://cs.chromium.org/chromium/src/chrome/BUILD.gn?q=enable_stripping&sq=pa...

I don't know why they aren't being considered outputs.

For the stripping, the BUILDCONFIG probably needs to be updated with an is_ios
condition as well:
https://cs.chromium.org/chromium/src/build/config/BUILDCONFIG.gn?q=mac:strip_...

+  }
 }
 
 bundle_data("cronet_test_bundle_data") {
@@ -153,6 +179,9 @@ copy("cronet_package_copy") {
     "//components/cronet/ios/Cronet.h",
     "//components/cronet/ios/cronet_c_for_grpc.h",
   ]
+  if (!is_debug) {
+    # sources += [ "$root_out_dir/Cronet.dSYM" ]

[mef, 2016/06/30 21:29:06]

Is there a way to specify that Cronet.dSYM is generated by cronet_framework
target?

[Robert Sesek, 2016/06/30 21:43:15]

The toolchain lists it as an output if based on the above condition I
highlighted.

[mef, 2016/07/01 14:10:08]

The toolchain just adds it to outputs:
https://cs.chromium.org/chromium/src/build/toolchain/mac/BUILD.gn?rcl=0&l=236

but when I try to do the same inside of
ios_framework_bundle("cronet_framework")" 

outputs += [ "$root_out_dir/Cronet.dSYM" ]

I get the error:

ERROR at //components/cronet/ios/BUILD.gn:112:5: Undefined variable for +=.

It seems that |outputs| in template is not the same as |outputs| in target?

+  }
   outputs = [
     "$_package_dir/{{source_file_part}}",
   ]