xctool does not respect the 'OS' or 'platform' fields in the -destination option. #205
Comments
|
A PR for building universal binaries is up: #211 |
|
A PR for using * DVTiPhoneSimulatorRemoteClient.framework* is up: #212 |
ghost
assigned
|
@fpotter My SimulatorHost.framework is actually in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/PrivateFrameworks/SimulatorHost.framework. Was your path a mistake, or are there multiple system configurations that need to be accounted for? |
|
@ryanrhee Oh, my mistake! Your path is right. |
|
@fpotter looking for a corresponding .deviceinfo bundle isn't going to work. Check this out - This really makes me want to have a separate configure step or something that figures this stuff out and saves the results. Parsing through all these files on every run might cost us a couple of seconds. |
|
Oh that's lame - it was so close to being that easy.
What do you mean by that? Like a machine-wide configure step for xctool? |
|
Yeah, like after installing, doing some sort of initialization to do some one-time set up that doesn't change very often. Anyway, that can come later. It seems like we're not losing too much time from this. |
|
Yeah, sounds good. It's only a few files - I bet it still runs super fast. |
|
@blakewatters Can you share the command line you're using to select the sim and iOS version? I don't think we knew about this specific bug... but let's fix it. |
|
@fpotter sure:
Always gets the 7.0 Simulator |
|
To expand a bit, the equivalent
works as expected |
|
Yeah, we only look at the name portion so far. We need to respect the OS part, too. https://github.com/facebook/xctool/blob/master/xctool/xctool/RunTestsAction.m#L347 sheesh... being a front-end for Xcode 4's xcodebuild was easy... but the Xcode 5 changes are a lot of work 😢 |
|
@fpotter I spent a couple of minutes spinning through the code and its not obvious to me how the destination argument is used once it passes into the |
|
man I must be blind or missing something, but I can’t see how the |
|
The SimulatorLauncher guyt handles that stuff. Over here -- And, then we're mucking with plists over here -- Presumably there's another plist key for OS version which we should also be setting. |
|
But with Xcode 5 you don't have to handle plists, you can use the -device argument |
|
Support of |
When running application tests, xctool should start the simulator named in the -destination parameter.
e.g., if you pass xcodebuild
-destination "name=iPad Retina", it will start the iPad Retina simulator. Or, if you pass-destination "name=iPhone Retain (3.5-inch)", it will start the 3.5in retina simulator.Making this happen is tricky, since the private framework we use for starting the simulator (iPhoneSimulatorRemoteClient.framework) doesn't expose methods for setting the device name.
We might want to switch to using DVTiPhoneSimulatorRemoteClient.framework which is much like the current framework we use, but with more options.
Or, we could try and trick iPhoneSimulatorRemoteClient.framework into sending the right messages we need. When watching Xcode.app post distributed notifications to the simulator, we can see that it's passing stuff like
deviceInfo=iPhone Retina (4-inch)in the com.apple.iphonesimulator.startSession message (see https://gist.github.com/fpotter/6941760). We might be able to swizzle our way into making iPhoneSimulatorRemoteClient.framework do the same thing.To validate that a device name is correct, we should look for a corresponding
.deviceinfobundle under /Applications/Xcode.app/Contents/Developer/Library/PrivateFrameworks/SimulatorHost.framework/Versions/A/Resources/Devices.The text was updated successfully, but these errors were encountered: