Change the default script for Objective-C to xctool

[sarahhodne]

This changes the default build script for Objective-C build to use xctool if a valid configuration is passed.

I'm not completely sure about the config variable names. If we prefix them with xcode_ we'll maintain backwards compatibility, although the old variables were never documented. I should probably check if anyone is using them.

TODO:

• Print a warning if the config is invalid. That is, the scheme or either the workspace or project is missing.
• Test on staging.

To the people I'm about to ping to ask to do a quick sanity check on this:

This change makes xctool the default script if a scheme is specified in the .travis.yml file, like this:

language: objective-c
workspace: YourWorkspace.xcworkspace
scheme: YourScheme

Does it seem good to require workspace/project and scheme? Can one or more be left out, or should I include more? There's also xctool_args, which can be added to pass arbritary args to xctool, like -sdk.

The above config will run this command:

$ xctool -workspace YourWorkspace.xcworkspace -scheme YourScheme build test

Should the default command be something else?

[sarahhodne]

Here's an example of a build using this code: https://staging.travis-ci.org/henrikhodne/Mantle/builds/387513.

[fpotter]

Excited about this :-)

Requiring workspace and scheme sounds good to me. xcodebuild doesn't require it, but that probably leads to weird ambiguity when there are multiple schemes or maybe an xcworkspace and xcodeproj in the same dir. Making it explicit sounds good.

We might also want to make sdk required, too. (Or, probably make it default to iphonesimulator since the test action won't work for the iphoneos SDK)

Let's say you had a regular iOS project and did the following with just the build action...

xctool -workspace YourWorkspace.xcworkspace -scheme YourScheme build

xctool will probably build your app against the device SDK iphoneos rather than iphonesimulator since that's probably the default in your iOS project and that's what xcodebuild would do.

But, if you did build and test...

xctool -workspace YourWorkspace.xcworkspace -scheme YourScheme build test

Now, xctool is going to build against the iphonesimulator SDK. When it sees the test action for an iOS project, it just defaults to iphonesimulator since it doesn't know how to run tests on device (yet).

Making SDK explicit (or setting the default to iphonesimulator) would make the SDK selection less ambiguous.

[sarahhodne]

I have to admit I'm not so sure about changing this after I found out that xctool doesn't support CocoaPods out of the box (due to the "find implicit dependencies" bug, see facebookarchive/xctool#16). Thinking about good ways to work around this.

[fpotter]

@henrikhodne Yeah, I'm going to look at that really soon. It seems fixable.

[joshk]

Any updates on this issue?

[fpotter]

@joshk I'm working on making xctool play nice with implicit dependencies right now. Will follow up in a bit when I get it figured out.

[fpotter]

@henrikhodne, @joshk hey guys, as of last week, xctool will play nice out-of-the-box with CocoaPods and other projects that use Xcode's Find Implicit Dependencies feature. This is in the 0.1.7 release, which is up on homebrew now. I've also put up binary releases if that makes life easier for travis-ci. (https://github.com/facebook/xctool/releases)

[sarahhodne]

@fpotter Thanks. I need to revamp the way we update our VMs and workers, will look into this soon, though.