Summary: User plugins, which are plugins at `~/Library/Application Support/Developer/Shared/Xcode/Plug-ins`, can cause issues if linked into the same image as a process that already references the same symbols. In order to save time and prevent runtime linker issues it makes sense to bypass the loading of these symbols. The simplest way of doing this is swizzling the bundle loader method and log/no-op in the event we have one of these bundles.
Reviewed By: mmmulani
Differential Revision: D3392950
fbshipit-source-id: cf173c8bd548d2b26d8cbc4dbb27d226582bf036
Summary: This slipped through the net in the `xcconfig` move. Should help compare settings between the four main Frameworks
Reviewed By: marekcirkos
Differential Revision: D3391969
fbshipit-source-id: 3e3f540d0d899925a8211a64bcae98c6412e54e0
Summary: This allows `FBDeviceControl` to be embedded in swift Framework targets.
Reviewed By: marekcirkos
Differential Revision: D3391967
fbshipit-source-id: f6962410783490b4a707ba3732fb14e4b837c142
Summary: This will allow Devices and Simulators to have a common formattable as well as share the class-cluster of configuration.
Reviewed By: marekcirkos
Differential Revision: D3391965
fbshipit-source-id: acc6e066a614cf0b01aef207cfa66ac1c4d4a396
Summary: These are part of `FBControlCore` and are important for defining configuration. Making them public allows consumers of the configuration obtain information about available architectures for a Simulator.
Reviewed By: marekcirkos
Differential Revision: D3384607
fbshipit-source-id: 34c447754198aea6b07ffa46ef9aea0a49a22a21
Summary: By moving `FBSimulatorQuery`'s model to `FBControlCore` it's possible for `FBDeviceControl` to then use a query for fetching. The only leakage of Simulators back to `FBControlCore` is the State enumeration. In future I may want to consolidate this with Device states.
Reviewed By: marekcirkos
Differential Revision: D3384602
fbshipit-source-id: 6f3ac5282dc8b94f2f3c458a8e9695d317aab4ce
Summary: In the same way that we have the archs of valid Device binaries, we can have the same for Simulators given that iPhone 5s and later started allowing 64-bit executables.
Reviewed By: marekcirkos
Differential Revision: D3384593
fbshipit-source-id: 11b6266915bafbb2275c51241051fccb4fa6fd18
Summary: `FBControlCore` has some target-specific setting that can be extracted to the truly wonderful world of human editable text files.
Reviewed By: marekcirkos
Differential Revision: D3371032
fbshipit-source-id: 952995d4358ae2e5e8e713659992128da1a9fcc9
Summary: There are a few relevant target-specifc settings that we can move to the magical world of plaintext.
Reviewed By: marekcirkos
Differential Revision: D3371030
fbshipit-source-id: c368f0228fcb0f1acbddef6650d8ec0413cc234c
Summary: These are yet again duplicate at the target level, so pulling these back to the `xcconfig`
Reviewed By: marekcirkos
Differential Revision: D3371024
fbshipit-source-id: ee1a0382ae75f61108b23b8ba4ce335f78974083
Summary: On Xcode 7.2, the `SimDevice` doesn't contain a reference to it's `SimDeviceSet`. Since we have a strong reference to this in `FBSimulatorSet` we should use this instead. Otherwise the `deleteSimulator:` method will fail since the set is `nil`.
Reviewed By: asm89
Differential Revision: D3379576
fbshipit-source-id: dfb6be4253aaf261f987817bdd75311b3cad3213
Summary: These are varied per-configuration (Debug/Release) instead of per-target, so I'm leaving them at the project level for now and instead removing them at the target level.
Reviewed By: marekcirkos
Differential Revision: D3371021
fbshipit-source-id: af5f9069f450477d8c3cf2efa39a536b545e6493
Summary: This is yet again shared between targets, and not even needed. We just need to appease the Xcode Framework codesign warning
Reviewed By: marekcirkos
Differential Revision: D3371018
fbshipit-source-id: c402ffb07831b95a42e83b356bd6bfa71261d362
Summary: Knowing the available architechtures for a given device configuration is important to identify whether an Application can be installed on a device. All of this configuration is static, we can just add the archs to configurations over time and as new devices are released.
Reviewed By: marekcirkos
Differential Revision: D3378183
fbshipit-source-id: 80c44d9aff1a1267ff338db1b2d1df37892543b8
Summary: Apple uses names like `iPhone8,1` to mean 'iPhone 6s'. These can be mapped to their more appropriate names so long as we have the configuration in the Framework. The Configuration Variants that `FBSimulatorControl` has used for determining parameters for `CoreSimulator` can have additional propreties added to expose these model identifiers.
Reviewed By: marekcirkos
Differential Revision: D3372419
fbshipit-source-id: 13ad7af4f5600b12f653b86ef522ab15b488456d
Summary: Moving this to `FBControlCore` will allow `FBDeviceControl` to augment elements within the class cluster, with model device ids from `MobileDevice.framework`. These can be used to map a variety of strings and identifiers to configurations for a device/simulator
Reviewed By: marekcirkos
Differential Revision: D3378176
fbshipit-source-id: 46cac9dc4055865801547055b7f206a53a8c4265
Summary: Pegs these as global for all Frameworks, in one convenient location!
Reviewed By: marekcirkos
Differential Revision: D3371013
fbshipit-source-id: 29d77b8935d4e9d20fb400af7aefeabac42bb1a7
Summary: Moving more to `xcconfig` files for readability, editability and source control tracking.
Reviewed By: marekcirkos
Differential Revision: D3371012
fbshipit-source-id: 5432bb6c5357615a5352004cdeadfc81bea66c0b
Summary: `FBSimulatorControl` hides the intracacies of `CoreSimulator` behind it's API, so the weak-linking of these Frameworks can be restricted to `FBSimulatorControl` alone.
Reviewed By: marekcirkos
Differential Revision: D3371009
fbshipit-source-id: 34ece3907bb1eb41202bd347bd2666fea918c545
Summary: Extracts the flags that are provided to the linker to the `xcconfig` file so that the `pbxproj` is trimmed down.
Reviewed By: marekcirkos
Differential Revision: D3366469
fbshipit-source-id: a87149865b37f79ebeca7bdd6ab63ff805371a5d
Summary: There are few more Properties that can be resolved from `MobileDevice` instead of `DVTFoundation` and associated plugins, we should use those
Reviewed By: mmmulani
Differential Revision: D3339826
fbshipit-source-id: 194648c4fb38865c7ad4602109ad052c5c51d7ce
Summary: These are all inherited from the `xcconfig`, so there's no need for these to be re-declared in the project itself.
Reviewed By: marekcirkos
Differential Revision: D3365235
fbshipit-source-id: 51bda23ab1427f92cc9b7be4715bbbeb667a92d2
Summary: Instead of the copypasta of the `xcconfig` files, it makes more sense to move these definitions to a shared configuration, which is then `#include`d from the other configurations. The configuration that is currently in the `FBSimulatorControl.xcodeproj/project.pbxproject` can then be extracted out to the per-target files. This can aid migration to GitHub buck builds and possibly a public workspace instead of a massive project.
Reviewed By: marekcirkos
Differential Revision: D3365232
fbshipit-source-id: b8234da1abff44c8525d9298599d632dba928fa2
Summary:
There's a build warning as `ALWAYS_SEARCH_USER_PATHS` is set to `YES`. This apparently conficts with the `DEFINES_MODULE` setting:
```
Warning: using 'ALWAYS_SEARCH_USER_PATHS = YES' while building targets which define modules ('DEFINES_MODULE = YES') may fail. Please migrate to using 'ALWAYS_SEARCH_USER_PATHS = NO'.
``
Reviewed By: marekcirkos
Differential Revision: D3365231
fbshipit-source-id: bce03f42a75f8014d55586fefa01a85db0d59876
Summary: Exposing Bulk erase/kill/delete methods completes the `FBSimulatorSet` API and will allow for the optimisation of the strategies these operations depend on. For example, deletion can be sped up in bulk by killing multiple Simulators at the same time and then waiting for `CoreSimulator` to show the state change before deleting.
Reviewed By: marekcirkos
Differential Revision: D3365230
fbshipit-source-id: 52d11460abb42ef8aaf930d739f3b1fe4c8b3869
Summary: Moving this check into the strategy means that the caller doesn't have to. Also simplifies object construction.
Reviewed By: marekcirkos
Differential Revision: D3365228
fbshipit-source-id: 4f39a5bf9b24d89fa5d3019b03c57e65bee74730
Summary: The Strategy is specialised to understand how erasing works. Moving membership checks here means that the caller doesn't have to concern itself with these checks.
Reviewed By: marekcirkos
Differential Revision: D3365226
fbshipit-source-id: b41c177d5c5b1418b0c0db380a086dfc16d9485b
Summary: The Constructor can get the logger ref instead of the constructor caller
Reviewed By: migchez
Differential Revision: D3360019
fbshipit-source-id: fe891c518acf4491c467573a94381240d4bdae5a
Summary: This can appear to result in some occasions where files will still be open from the erase which then cause the deletion to fail. It's far simpler to delete the Simulator and just delete the log directory after the fact.
Reviewed By: nqmtuan
Differential Revision: D3358515
fbshipit-source-id: 4c927fb6a1b3264f6f51e3a83b5ca40b999294af
Summary: Erasing before deletion is a wise move as it will also catch the substantial number of logfiles that deletion does not located in `~/Library/Logs/CoreSimulator/<UDID>`. This will ensure these hefty logs aren't left lying around when you really wish to obliterate a Simulator.
Reviewed By: nqmtuan
Differential Revision: D3352817
fbshipit-source-id: e3776766699668a561076f890a0482adb0d8ffb3
Summary: `FBDeviceControl` is very experimental, let's add a `README` to highlight this
Reviewed By: marekcirkos
Differential Revision: D3352345
fbshipit-source-id: 55a4c8db73d066a92e051b9390625e0afbd32c0f
Summary: This contains a lot of interesting goodies, so it's handy to have as a public API. Additionally, these Logs have a tendency to accumilate so may need to be erased.
Reviewed By: marekcirkos
Differential Revision: D3352228
fbshipit-source-id: 3f6d38b7309dc1e961c883a3cf77f3f9ff014f19
Summary: `FBSimulatorControl` includes logs as they are pretty helpful when running tests, `FBDeviceControl` can do the same.
Reviewed By: mmmulani
Differential Revision: D3339825
fbshipit-source-id: bce3a73e6fccc313704a370246f7d3b1d55f8924
Summary: The loading 'Xcode Frameworks' can be deferred until they are needed, allowing certain APIs to be used without requiring loading these Frameworks at all. Splitting the initialization defers expensive Framework loading until it is actually needed. The `DVT` classes are also loaded from the Device Set lazily since we need to 'prime' the device set in order to obtain valid devices from it.
Reviewed By: mmmulani
Differential Revision: D3339824
fbshipit-source-id: fbea89c5934c5517071aa38d19b17f8d782a9d49
Summary: It will be possible to bypass using the `DVT` classes for some subset of public API. By deferring the usage of the `DVT` classes, we can later defer the linking of these classes.
Reviewed By: mmmulani
Differential Revision: D3339822
fbshipit-source-id: 3bd9a98077be8b722559518ea7b606815039aae0
Summary: The UDID and Name are somewhat confusing. The Name is the Name of the Device specified by the user, the UDID is obviously unique. Also adds the function prototypes to the header.
Reviewed By: marekcirkos
Differential Revision: D3334170
fbshipit-source-id: cd80292556c9e8479aa6d995961e80c57f5bddc8
Summary: There are a number of states that could use further logging in order to trace the ordering of events in the event of a failure.
Reviewed By: nqmtuan
Differential Revision: D3341312
fbshipit-source-id: 16bff9e61f869968b58bccf5d1a7558a4188b2a3
Summary: Improves the state transitions inside `FBTestBundleConnection` by providing separate error and success conditions. The 'Connecting' state was never set, which needs fixing. Some of the logging inside `FBTestBundleConnection` was a little lacking.
Reviewed By: nqmtuan
Differential Revision: D3341203
fbshipit-source-id: 33bdf82ab127f0b3aa082ae084c55c58512314c4
Summary: Currently the underlying error from Framework errors are ignored if the error cannot be categorized. This fixes that.
Reviewed By: mmmulani
Differential Revision: D3339820
fbshipit-source-id: c8361c0de5d0b744a62823a8c394c90233550d91
Summary:
It's possible to pass `NSUserDefaults` on the Command Line instead of setting globally for the whole Simulator.
Using a model to represent ways of setting the arguments via a defaults plist and other arguments. If we decide to later, we may be able to add additional configurable overrides for keyboards etc.
Reviewed By: marekcirkos
Differential Revision: D3328191
fbshipit-source-id: 37688698880aa33210f26f8e9581d1f90228dd00
Summary:
Fix#263
Please let me know if I can improve something. Please see also my comments in #263 about the retrying strategy of Xcode. Once you "listen" to the `XPC` communication, you'll notice that Xcode is also just trying different methods and ignoring errors.
Closes https://github.com/facebook/FBSimulatorControl/pull/264
Differential Revision: D3333334
Pulled By: marekcirkos
fbshipit-source-id: a14faff8828e3896577fa8be58395de9a0935268
Summary: This can become the common protocol that Devices & Simulators provide. The Target can then expose a set of Commands, which will allow callers of the API to use the methods for Devices & Simulators. We can add to this Protocol over time as more common behaviours for Devices & Simulators become available.
Reviewed By: marekcirkos
Differential Revision: D3322073
fbshipit-source-id: fe308861975324f4ba750abdce9330ad63697d0d
Lawrence Lomax
Johannes Plunien