-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Playground #26
Comments
Was this an iOS playground or an OS X one? I got this working on the OS X one only so far. See commit facb6cd |
Nope, this was OS X playground... But I had the same error message: I've also checked other well known frameworks to see how they handle this issue. For example Alamofire has internal Playground working only on iOS. |
Personally I think both frameworks should be named the same to avoid conditional imports on a library using this as a dependency. Esteban Torres On Sun, Jun 21, 2015 at 11:36 AM -0700, "Mateusz Zając" notifications@github.com wrote: Nope, this was OS X playground... But I had the same error message: From my POV, I also think that the issue is what @czechboy0 pointed in this commit. On the other hand, do we really need to name PRODUCT_NAME differently? Can't we only use OS X or iOS playground (matter of choice) and have in mind that this is the issue? Final user won't have this problem as he/she will get the proper framework file. — |
I agree with @esttorhe. What we want is to provide an easy way of importing |
Sure, it's just annoying we'll have a playground that doesn't actually include our framework correctly (the iOS one). Let's leave it this way for now though and if anyone finds out a way to make both iOS and OS X playgrounds work, please comment on this issue. @cojoj Please close this if there's no other action required. |
I'll play today a little bit and try to make it work as expected |
👍 |
I made it work with some hacks here and there… 😒 Here's the Here's the I had to configure a custom build path on the workspace settings (I don't think this is needed but it was part of my explorations); biggest issues are that in order for the Playgrounds to work the deployment targets need to be downgraded:
Look at this: neonichu/quick-cli-runner#3 Long story short; I don't think the benefit is worth the hassle; I'm going to push this to another branch in case you want to take a look at this implementation ¯_(ツ)_/¯ |
Here's a fork with the workaround: In case you need to change the paths go to:
But I think the complexity far outweighs the benefits IMHO |
@esttorhe thank for sorting it out... I think that if we have a solution and we're aware of consequences we can agree that one Playground platform is sufficient for our usage 😉 |
I agree; its better to nuke 🔥 the |
I've investigated some projects which follows the pattern of having
.xcworkspace
in which they have Framework itself, sample project and also a Playground (using framework) and after digging I can confirm that we have everything to run this pattern!Here's a proof:
As you can see I can
import XcodeServerSDK
and use it in Playground with code completion etc.Earlier the problem was with wrong configuration of Playground (was targeting iOS while framework support OS X only). I think we have solution to this issue in #24 and also this matter was explained in by @esttorhe in #25.
I'll check this PR tomorrow and if everything will work fine I will strongly suggest to merge it.
The text was updated successfully, but these errors were encountered: