Rework iOS recipes to use latest MB approach

scripts/slave/recipes/ios/try.py

Index: scripts/slave/recipes/ios/try.py
diff --git a/scripts/slave/recipes/ios/try.py b/scripts/slave/recipes/ios/try.py
index 8b11abba83a9bcbc744b317bae27f4b88e88752e..8e57d47a34074a5f3cbe0c79e0bc45ab07d14ef0 100644
--- a/scripts/slave/recipes/ios/try.py
+++ b/scripts/slave/recipes/ios/try.py
@@ -209,7 +209,8 @@ def GenTests(api):
           'os': '8.1',
         },
       ],
-      'use_mb': True,
+      'mb_type': 'gn',
+      'gn_args': 'target_os="ios" ios_enable_code_signing=false',

[smut, 2015/11/10 22:01:18]

Can this be a dict like gyp_defines?

[Dirk Pranke, 2015/11/10 22:34:15]

I actually don't think modeling gyp_defines as a dict is a good pattern to
follow.

It's not how GYP (or GN) actually gets them, and modeling them as either Python
dicts or JSON dicts introduces type and quoting uncertainties that you have to
write code to account for. In particular, GN uses C++-style syntax, not python
syntax, so you have to use "true" instead of "True" and '"ios"' instead of
'ios'.

You also end up potentially hiding (or duplicating) the work that GN and GYP
will do automatically to de-dup arguments.

But, if I can't convince you that treating these things as strings instead of
dicts is the right way to go, we should probably make the gn args a dict.

[smut, 2015/11/10 23:25:34]

It's hard to parse the diff when someone updates one really long one-line string
with another. I prefer these values to be enumerated alphabetically so the diff
is really easy to see. That's really where my choice of dict came in. I didn't
realize at the time that it could be problematic.

How about a list of strings? gn_args = [
  'ios_enable_code_signing=false',
  'target_os="ios"',
]

Just to ease legibility of the config itself and especially diffs in CLs.

[Dirk Pranke, 2015/11/10 23:59:37]

True, that's a good point. 

GN actually takes the space-separated string of args and writes them to a
newline-separated list of args in out/Release/args.gn .

So there's some precedent that suggests that multi-line is good, though we'd
have to rework MB to take a multiline string if we actually wanted to pass it
through as is (or write the args.gn file directly and tell MB to just use that).

I will think about this some more.

[smut, 2015/11/11 00:08:09]

Just add ' '.join(self.__config['gn_args']) in ios/api.py for minimal work. It
already does that for gyp defines.

     })
   )