Bug 133963 – Add knowledge of the iOS Simulator to webkitpy

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Simon Fraser (smfr)]

Add knowledge of the iOS Simulator to webkitpy

[Simon Fraser (smfr)]

Created attachment 233206 [details]
Patch

[WebKit Commit Bot]

Attachment 233206 [details] did not pass style-queue:


ERROR: Tools/Scripts/webkitpy/port/ios-simulator.py:88:  no spaces around keyword / parameter equals  [pep8/E251] [5]
ERROR: Tools/Scripts/webkitpy/port/ios-simulator.py:122:  multiple statements on one line (semicolon)  [pep8/E702] [5]
Total errors found: 2 in 4 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Brent Fulgham]

Comment on attachment 233206 [details]
Patch

I think this looks good, but perhaps Ryosuke should review.

[Simon Fraser (smfr)]

David Farler should also say whether this will be useful to him.

[David Farler]

Here's some feedback based on the simulator relay app I'm working on:

You can just use "LayoutTestRelay" as the driver for both DRT and WKTR.

--app
I've been using --app /path/to/DRTorWKTR.app which I install with CoreSimulator.

--suffix
In order to support multiple copies of the dump tool running simultaneously, they need to have a unique bundle identifier. LayoutTestRelay can handle this but it needs to have a suffix passed to it so it knows how to unique the identifier (LayoutTestRelay and DRT/WKTR instances are 1:1). I've been using --suffix {1..N} depending on how many instances are passed in as the option.

--product-dir
To set DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH when launching in the simulator. I can also just pick these up from the environment.

--A way to specify the device type.
CoreSimulator spawns devices as (SimDeviceType, SimRuntime) -> SimDevice. For any device type, I'll have to do a check to see if the device and runtime are compatible, since you can have more than one simulator runtime in an Xcode.app bundle. They are identified by reverse-DNS style identifiers. It would be easiest to provide both --deviceType <identifier> --runtime <identifier> to the relay app, where I can do a quick check and bail if the combination is invalid.

Simulator device types roughly correspond to iOS hardware models, and simulator runtimes correspond roughly to simulator SDK versions.

[David Farler]

Yoink.

[David Farler]

Comment on attachment 233206 [details]
Patch

Got a bunch more changes on top of this. Will upload another patch.

[David Farler]

Created attachment 235481 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 235481 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=235481&action=review

> Tools/ChangeLog:16
> +        * Scripts/webkitpy/port/ios.py: Added.

can we call this iossimulator.py ?

> Tools/Scripts/webkitpy/port/ios.py:50
> +    ARCHITECTURES = ['x86_64', 'x86']

We should probably support 32-bit too.

[David Farler]

(In reply to comment #9)
> (From update of attachment 235481 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=235481&action=review
> 
> > Tools/ChangeLog:16
> > +        * Scripts/webkitpy/port/ios.py: Added.
> 
> can we call this iossimulator.py ?

We can, but I was just going to put the simulator and device support (when that is ready) in the same module, since they will both run in more or less the same way. Eventually we will have an IOSDevicePort and it makes sense for them to be in the same Python module.

> 
> > Tools/Scripts/webkitpy/port/ios.py:50
> > +    ARCHITECTURES = ['x86_64', 'x86']
> 
> We should probably support 32-bit too.

Ah, I copied this from the Mac, I assumed that’s what ‘x86’ was. It looks like x86 is webkitpy-speak for i386:

mac.py:72:def _build_driver_flags(self):
return ['ARCHS=i386'] if self.architecture() == 'x86' else []

[David Farler]

Committed r171789: <http://trac.webkit.org/changeset/171789>