xctool Always Uses System Xcode Path

[SlaunchaMan]

We have xctool installed on our Jenkins instance to do our CI work on our iOS projects. Problem is, we have a lot of clients and a lot of apps. Some of our apps have moved to iOS 7, while others are back on iOS 5 (when you a bunch of products through the app, you can’t exactly cut out 5% of users). It would be great if we could have Xcode 5 through the App Store and Xcode 4.6.3 installed simultaneously.

xctool uses the system Xcode path from xcode-select, so AFAIK there is no way to do this without using xcode-select in our build path to select the path before running. Since xcode-select needs to be run with sudo, the only options there are to run the build script with higher permissions (bad), use the setuid bit on xcode-select to make it always run as root (gross), or make a script somewhere with the setuid bit set and have it pass arguments to xcode-select (eww).

If instead we could pass a path to xctool, well, that’d be great.

[SlaunchaMan]

I went ahead and wrote detroit-labs/safe-xcode-select as a temporary workaround, but that requires compiling it and installing it on your server.

[ryanrhee]

I think this is a good feature to have. We'll look into it. Thanks for the report!

[orj]

why not just use xcrun to invoke xcodebuild?

xcrun will honour the DEVELOPER_DIR environment variable to select which xcodebuild to use.

[fpotter]

There actually is a workaround for this, but we've never documented it. Like @orj points out, Xcode's command line utilities will honor whatever path is found in the DEVELOPER_DIR environment var.

If you do ...

DEVELOPER_DIR=/Applications/Xcode4.6.3.app/Contents/Developer xctool ...

... the right things will happen.

Internally, xctool is always calling xcode-select --print-path to determine which Xcode install to use, but xcode-select itself honors DEVELOPER_DIR.

[SlaunchaMan]

This is a little late, but thanks! We’re upgrading our CI system and this means there’s one less thing we have to do.