Fix Carthage support

[ishkawa]

Could not install OHHTTPStubs using Carthage if iOS 7 simulator is installed. The cause of failure is xcodebuild misunderstands deployment target as 6.0, which is from OHHTTPStubs iOS Tests, so I separate tests target for iOS framework from OHHTTPStubs iOS Tests. This might be a bug of xcodebuild, but we need a workaround for now.

NOTE: this is not bug of Carthage because this can be reproduced by xcodebuild -scheme "OHHTTPStubs iOS Framework" -workspace OHHTTPStubsDemo.xcworkspace.

Cartfile:

github "AliSoftware/OHHTTPStubs" "master"

Output:

*** Fetching OHHTTPStubs
*** Checking out OHHTTPStubs at "02cc9fcc0cdfca79e1968df9e3e072c256e5e593"
*** xcodebuild output can be found in /var/folders/0j/p83b0p397sz3y910bvz9_1wh0000gn/T/carthage-xcodebuild.LTKmmE.log
*** Building scheme "OHHTTPStubs iOS Framework" in OHHTTPStubsDemo.xcworkspace
xcodebuild: error: Failed to build workspace OHHTTPStubsDemo with scheme OHHTTPStubs iOS Framework.
    Reason: The run destination iPad 2 is not valid for Running the scheme 'OHHTTPStubs iOS Framework'.

[AliSoftware]

Mmmmh. Probably an xcodebuild bug indeed.

So as I understand it, you duplicated the iOS Unit Tests target to assign this copy to the iOS Framework target and change its Deployment Target, right?

Maybe it would be simpler just to remove the test target from the framework scheme altogether rather than having two duplicate targets to maintain.

After all, the Unit Tests target only contains functional tests (there is no integration test or whatnot in there), so as long as one can run those tests, it should be ok. The only important thing here is that the test can be run, making them run from the static lib or framework shouldn't change their behavior, so only having them associated with the StaticLib scheme should be sufficient, right?

[AliSoftware]

Hey, just for my information, because I'm not that familiar with Cartage yet:

Could not install OHHTTPStubs using Carthage if iOS 7 simulator is installed

Isn't Carthage only supposed to use/be compatible with iOS dynamic Frameworks? And as frameworks are only supported since iOS8, how come you try to run it with iOS7 simulator then?

Is that supposed to work at all? I mean iOS7 + frameworks are not compatible in the first place anyway, right?

[ishkawa]

Yes, you are right. I will remove duplicated test target and remove test target from iOS framework scheme.

[AliSoftware]

Thanks.

Note the original error still seems to make sense for me, regardless of the test target stuff:

xcodebuild: error: Failed to build workspace OHHTTPStubsDemo with scheme OHHTTPStubs iOS Framework.
    Reason: The run destination iPad 2 is not valid for Running the scheme 'OHHTTPStubs iOS Framework'.

if your destination is using the iOS7 runtime, this error makes sense as iOS7 is not compatible with dynamic frameworks that was introduced with iOS8, so I'm not sure your error originates from the test target after all.

[ishkawa]

Carthage supports dynamic framework only, thus it supports iOS 8 or later and all of OS X. And I did not try to build OHHTTPStubs.framework for iOS 7 runtime (iOS 8 or later only).

The problem is we can not build framework by xcodebuild -scheme "OHHTTPStubs iOS Framework" -workspace OHHTTPStubsDemo.xcworkspace, and this means we can not install OHHTTPStubs using Carthage. This is caused by xcodebuild bug and that OHHTTPStubs iOS Framework scheme has test action with lower deployment target. Please try the command above on both of master and forked repository.

[ishkawa]

I noticed this also happened on Travis CI before.
https://travis-ci.org/AliSoftware/OHHTTPStubs/builds/52363629

This error is avoided by adding -destination option of xcodebuild, but Carthage cannot do that.

[AliSoftware]

Maybe you should file an issue to Carthage then, right?

I mean, given what you describe, that issue is with xcodebuild and Carthage, so OHHTTPStubs is by far not the only framework this issue will be happening with; it's gonna be problematic with every library out there on GitHub having the same kind of configuration…

[ishkawa]

Unfortunately, they decided that they will not add workaround for the similar issue.
Carthage/Carthage#259

Anyway, their requirement is very simple, just making xcodebuild -scheme SCHEME -workspace WORKSPACE build succeeded. So I think this should be fixed by modifying library.

[AliSoftware]

Damn. I don't like that our libraries (I mean not just mine but any other lib developer's too) have to do workarounds for a tool that don't want to fix issues on their end 😢 Sad that Carthage does not want to fix that at the common place 😒

That means that if one wants Carthage support, we need to report this workaround on every of our libraries instead of fixing it at only one place directly on the tool that have the problem. And they told us that "there was nothing to do for lib developers to support Carthage out of the box" ahah…

I'll probably merge your PR anyway as it's ready to go, but integrating with CocoaPods or manual integration for example does not generate this issue when integrating iOS frameworks, so from my point of view it should still be up to Carthage to fix it…

[ishkawa]

Thank you for merging. I hope this will be fixed in future version of Xcode.