Fix issue where device builds would be installed in the simulator #71
Conversation
BUILD_DIR has multiple subfolders for different configuration/sdk combinations, which can result in an app being installed for the wrong architecture (e.g., a Debug-iphoneos build instead of Debug-iphonesimulator).
Previously we used Xcode's defaults for build configuration, which are determined using a combination of project settings and scheme action configuration. However, `xcodebuild -showBuildSettings` doesn't resolve build settings the same way it does when actually performing a build action, giving unexpected results when attempting to locate the correct build directory for running. Adding support for a configurable, explicit build configuration works around this problem, while also allowing users to build/test/run in Release configuration or a custom configuration.
Without the SDK set explicitly, `xcodebuild -showBuildSettings` defaults to `-iphoneos` for CONFIGURATION_BUILD_DIR. Passing through the destination unfortunately has no effect.
|
Honestly, I feel like if we're going to do this we should probably fall back to the scheme for this, even though it's more difficult. Does it help that we know the name of the selected scheme? We also have a list of the projects in the root of the repo. I guess it'd be more complicated if the project is nested somewhere but exposed through a workspace. One thing at a time, I suppose? |
|
I think the main issue is that the name is not enough to uniquely identify a scheme: i.e., you can technically have a scheme with the same name inside every project in a workspace, and inside the workspace itself. Xcode handles this by presenting all the schemes as a list, and if there are conflicts it places the project or workspace name in parentheses after the scheme name. So I think the way to handle this would be to always resolve a scheme name to an actual path on disk. When it comes to selecting a scheme, perhaps we could present a list of the matching schemes to the user and have them choose one? |
|
I was thinking that perhaps if a project was selected, rather than a workspace, we could assume there is only one matching scheme. But the. I remembered that nested projects are also a thing, so ¯_(ツ)_/¯ |
Fixes #66.
This is one possible solution to resolve an issue where device builds would be installed in the simulator, and then crash on launch because they are built for the wrong architecture.
The main problem I have with this as a potential solution is that we now completely ignore the configuration set in the scheme, in favour of an explicit configuration variable managed by vim-xcode.
However, the only alternative I've been able to think of is to add code to first locate and then parse .xcscheme files, so that we can then communicate various scheme parameters to
xcodebuild -showBuildSettingsandsimctl launch. This is possibly a little complicated, because it would involve writing logic to try and locate the correct xcscheme file to use. Parsing itself would be less complicated because we should be able to extract values with some straightforward XPath queries and something likexmllint.Love to know what you think of this approach, and whether we should just go for supporting more features of Xcode schemes.