why xcodebuild building the same application differently for scheme and target options?
xcodebuild -target uConnect build
Above commands builds with Release config in build folder inside
project.
xcodebuild -scheme uConnect build
Above builds with Debug config in Xcode’s DrivedData folder.
Wanted to understand what difference -target and -scheme options are making here?
As per my understanding it should always build the application in Release mode since we have selected Release at Project>>Info>>Configuration
use Release for command-line builds
Reference:
Screenshot of Scheme Details for reference
Try editing the scheme. You will see that it specifies the Debug configuration when building. It might look like this:
But, as you've said, when you build the target, you've specified the Release configuration.
A target describes a product that Xcode will build, like your app, the tests, an App Clip or an Extension. When using -target, it will use the configuration specified in the drop down at the bottom of your screenshot.
A scheme is a configuration that describes how a specific target will be built under different circumstances. If you go to the scheme editor, you'll see that you can choose which configuration to build when running, testing, profiling, analyzing, and archiving.
Related
I am using xcodebuild commandline tool to generate my ios app(mainly c++ source code). The command is like
xcodebuild -project Application.xcodeproj
I want to ask whether can I separate the build phase and package phase, that is to say, first build the binary executable, then at sometime package the app later.
From Apple technical note, xcodebuild supports various build actions such as build, analyze, and archive that can be performed on your target or scheme. However, build is performed by default when no action is specified. So, when you want to package, specify action archive otherwise just leave it empty as shown in Apple Example in the document.
This is my .travis.yml file
language: objective-c
osx_image: xcode7.2
script:
xctool -project ProjectName.xcodeproj -scheme ProjectName build -sdk iphonesimulator
While Travis is running I've got this error:
$ xctool -project ProjectName.xcodeproj -scheme ProjectName build -sdk iphonesimulator
ERROR: Cannot find schemes. Please consider creating shared schemes in Xcode.
TIP: This might happen if you're relying on Xcode to autocreate your schemes
and your scheme files don't yet exist. xctool, like xcodebuild, isn't able to
automatically create schemes. We recommend disabling "Autocreate schemes"
in your workspace/project, making sure your existing schemes are marked as
"Shared", and making sure they're checked into source control.
This problem is easy to solve:
Go to your project scheme and click Manage Schemes...
Tick Shared for your scheme
Click Close, commit and push.
Problem Solved. Now Travis is working without problems.
I also wrote a post in my blog about Travis-CI.
In addition to the answer by Gabriel.Massana, make sure the files are checked into version control (SVN/GIT).
I have a project that has multiple different targets/schemes (~38 of them as of writing this question) and I am trying to get unit testing working properly across all of the different targets. I got things working with one target, and tried adding my testing target to all of the different schemes, but it looks like when tests run for each scheme they actually run on the same, original target.
Looking in the project file I see that there's a specific Host Application associated with my testing target, and in the build settings the Bundle Loader and Test Host point to that same Host Application.
Is there any way to override those values for each scheme to run the tests against the current scheme's build target? Or some other way to set up a single test target to run across multiple build targets?
If you run the tests from the command line, or from an CI tool, like Jenkins, you can instruct xcodebuild to use the build settings that you provide. A simple usage example would be:
xcodebuild -scheme SomeScheme test TEST_HOST=target
You can control almost (if not any) build setting from Xcode, like code coverage generation, build directory, derived data directory, code sign identity, etc.
You can select the scheme when you run tests with Xcode server.
Look at WWDC 2014 continues integration talk for a walk through on how to set it up
https://developer.apple.com/videos/play/wwdc2014-415/
It's using Xcode 6 but it's very similar process to Xcode 7
Also check this CI(continues integration) guideline from apple
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/xcode_guide-continuous_integration/adopt_continuous_integration.html
If anyone is wondering how to do that with UI tests (maybe it is working with unit tests, too), this is what I came up with:
First, we need to build the application which we are going to use to host our UI tests:
xcodebuild -scheme "<appSchemeName>" build -destination "<yourDestination>"
More info about destination parameter: https://mokacoding.com/blog/xcodebuild-destination-options/
Then, we need to run tests on our newly built application:
xcodebuild -scheme "<uiTestsSchemeName>" -destination "<yourDestination>" test TEST_TARGET_NAME="<yourNewlyBuiltAppTargetName>"
Destinations should match, since after the build .app is generated in your DerivedData folder, which will be used for UI tests hosting application
In order to test localisation, I have an Xcode scheme configured to specify simulator locale settings. The scheme appears as follows:
-AppleLocale $(LANG)_$(COUNTRY)
-AppleLanguages ($(LANG))
Passing the above arguments to the simulator has the desired effect if LANG and COUNTRY are defined as build settings in the target.
For convenient automation, I'd like to be able to override the build settings from xcodebuild. However, when I run the following to override the target build settings, the locale of the simulator remains unchanged.
xcodebuild test -workspace MyApp.xcworkspace -scheme 'App UI Tests' -destination 'name=iPad Air' LANG=es COUNTRY=ES
It seems the default build settings from the target are used, regardless of any overrides specified at the terminal.
As an alternative, I could specify the locale code directly in the scheme. Then I could duplicate the scheme for every locale. It seems like a lot of duplication, but perhaps it is more the intended usage of schemes.
Am I missing something? Is this a feature of schemes by design, or could it be an issue with Xcode?
I'm trying to build my XCode project via the terminal. I'd like use Xcode's Product > Build for > Profiling option. So far I have:
xcodebuild -project "MyGame.xcodeproj" -target "MyGameEditor - Mac" -destination 'name=My Mac 64-bit' -configuration Profile
The project builds but not for profiling. I get an error that configuration 'Profile' does not exist.
Any help is appreciated.
What you are trying to sepcify with -configuration is the build configuration, not the build action. Unless you have added extra configurations to your project, you only have "Debug" and "Release" configurations.
What Xcode does when you tell it to profile is it builds the configuration that your scheme specifies to use when profiling, launches the simulator, installs the app, then launches Instruments.
So you need to do a similar thing with two command line calls, one to xcodebuild, one to instruments.
Some helpful links that should help you figure out what you need to do:
http://blog.manbolo.com/2013/04/09/launching-uiautomation-tests-in-command-line
Can the UI Automation instrument be run from the command line?
It is also worth noting that rather than specifying a target and configuration, you should just specify a scheme which provides both and other optional additional features.