Build the user_agent target for iOS

Build the user_agent target for iOS

This enables building just the user_agent target of webkit_support.gyp
on iOS, and adds iOS versions of the UA-construction utility methods.

Eventually the goal is for iOS not to build any code in webkit/, but
user agent is tied in to enough other code in webkit/ that it's
unlikely to be extracted in the short term, so adding minimal iOS
support to webkit_support.gyp is a necessary bridging measure.

BUG=None


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=156276

[stuartmorgan, 2012-09-10 14:53:15]

Tony: for review and OWNERS (the fiddly details of the iOS logic have already
been reviewed in our tree, so this is more for the overal structure of the
change).

John, Darin: FYI, since we discussed not building webkit/ code for iOS. UA is
going to start blocking us within a couple of days, and I really don't want
upstreaming progress blocked on getting DRT/TST/etc. off of the UA code so it
can move to content/. This is a short-term solution, and once UA isn't tied in
to webkit/ it can easily be undone. If you object, please let me know (and
ideally point me to someone with the experience and bandwidth to break all the
necessary connections to get this code out of webkit/ ASAP)

[tony, 2012-09-10 17:15:17]

https://chromiumcodereview.appspot.com/10905184/diff/1/webkit/support/webkit_...
File webkit/support/webkit_support.gyp (right):

https://chromiumcodereview.appspot.com/10905184/diff/1/webkit/support/webkit_...
webkit/support/webkit_support.gyp:12: # removed.
Is it problematic to include the gypi files but not depend on any of the unused
targets in the iOS build?  That seems like it would be cleaner (this file would
be unchanged, but all.gyp would be a bit more complicated).  That is, rather
than depending on webkit_support.gyp:*, the iOS build would just depend on the
specific targets it needs.

https://chromiumcodereview.appspot.com/10905184/diff/1/webkit/user_agent/user...
File webkit/user_agent/user_agent_util_ios.mm (right):

https://chromiumcodereview.appspot.com/10905184/diff/1/webkit/user_agent/user...
webkit/user_agent/user_agent_util_ios.mm:101: scoped_nsobject<NSDictionary>
dialects([[NSDictionary alloc]
Does this dictionary get created/deleted each time this function is called?

[stuartmorgan, 2012-09-11 09:42:54]

https://chromiumcodereview.appspot.com/10905184/diff/1/webkit/support/webkit_...
File webkit/support/webkit_support.gyp (right):

https://chromiumcodereview.appspot.com/10905184/diff/1/webkit/support/webkit_...
webkit/support/webkit_support.gyp:12: # removed.
On 2012/09/10 17:15:17, tony wrote:
> Is it problematic to include the gypi files but not depend on any of the
unused
> targets in the iOS build?

Yes. Project file generation is per gyp file, not per target, so gyp would
attempt to create all the targets from all the gypi files. It would be really
annoying to have targets that can't be built in the project, but more
importantly it would fail generation because some of the targets in turn depend
on gyp files that don't exist in the iOS tree, or that have an unsupported type.
So all the targets in all the gypi files would have to be made at least
iOS-generation-clean, which would be a bunch of changes that wouldn't really
make sense.

https://chromiumcodereview.appspot.com/10905184/diff/1/webkit/user_agent/user...
File webkit/user_agent/user_agent_util_ios.mm (right):

https://chromiumcodereview.appspot.com/10905184/diff/1/webkit/user_agent/user...
webkit/user_agent/user_agent_util_ios.mm:101: scoped_nsobject<NSDictionary>
dialects([[NSDictionary alloc]
On 2012/09/10 17:15:17, tony wrote:
> Does this dictionary get created/deleted each time this function is called?

Yes, but only the dictionary itself; the strings are part of the binary.

[tony, 2012-09-11 17:34:01]

Ok, LGTM

I would probably use CR_DEFINE_STATIC_LOCAL for the dict, but I don't feel
strongly about it.

[stuartmorgan, 2012-09-11 17:50:58]

On 2012/09/11 17:34:01, tony wrote:
> I would probably use CR_DEFINE_STATIC_LOCAL for the dict

Looks like it only works for C++ objects:

#define CR_DEFINE_STATIC_LOCAL(type, name, arguments) \
  static type& name = *new type arguments

I'll see how much this is called and decide whether it makes sense.

[stuartmorgan, 2012-09-11 17:51:23]

On 2012/09/11 17:50:58, stuartmorgan wrote:
> I'll see how much this is called and decide whether it makes sense.

... to do it manually, not using the macro that doesn't work for ObjC :)

[stuartmorgan, 2012-09-12 08:38:26]

It looks like it's only called once, generally, so I'd rather not have the extra
object living forever.

[commit-bot: I haz the power, 2012-09-12 08:38:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/stuartmorgan@chromium.org/10905184/1

[commit-bot: I haz the power, 2012-09-12 11:07:05]

Change committed as 156276