Support using from an OSX app
camelpunch opened this issue · 27 comments
- configure
- update docs to suit new / removed Carthage options
Is there an outline for what needs to be done in order to support OS X?
It hasn't even been investigated. I think we probably would copy what other frameworks like https://github.com/robbiehanson/CocoaAsyncSocket do. If you have a need for OSX then we can bump this up our backlog.
I have no pressing need for this at the moment. Would be glad to contribute but must admit I would need some guidance or general outline.
@glajdy investigating what currently doesn't work on OS X and what our dependencies such as CocoaAsyncSocket do would be a great way to contribute, too ;)
@michaelklishin I'll look into it and would be very glad to contribute :)
@glajdy this SO discussion might help: http://stackoverflow.com/questions/26811170/how-to-create-a-single-shared-framework-between-ios-and-os-x
Also, someone with more framework experience like @briancroom or @ratkins might be able to weigh in here.
Really quick - my impression is that it should be pretty straightforward to accomplish this. I noticed there are a few extraneous references to UIKit that should be cleaned up, but I know CocoaAsyncSocket works great on Mac already, so you're good there.
Regarding Xcode target structure, in the past I've always made separate framework targets for each platform, although that does get a bit unwieldy. It seems worthwhile to try the suggestion in the SO thread of configuring a target to support both platforms, although AFAIK it is still the case that Carthage wouldn't deal well with that setup.
Thanks Brian!
More on this topic! http://promisekit.org/news/2016/08/Multiplatform-Single-Scheme-Xcode-Projects/
@camelpunch Is there still the possibility of bumping this up?
I was able to compile an OSX application with a few minor tweaks
- Editing pod spec for osx support
- Changing @imports for CocoaAsyncSocket and JKVValue (Current application doesn't support use_frameworks yet)
however I didn't actually attempt make any connections yet.
@cswelin thank you so much! Feel free to use our Objective-C tutorials to test things out.
@cswelin: yes, we can bump this up our priority list. Thanks for looking into it for CocoaPods.
Please add me to the list of devs interested in this feature! Not just OS X support but Swift 3 too.
To that end, in the last few days, I forked and did a quick&dirty port to both, including two new targets: RMQClient_macOSX.framework and RMQClientTests_macOSX.xctest
This work is still raw, so while I'm just trying to be helpful and share with others having needs such as mine, caveat emptor! If anyone looks at my fork, note: 1) I didn't adhere to cocoapods/carthage, so beware the hard paths to the dependent frameworks; 2) While 240+ unit tests were passing, 4 are disabled, were crashing (not yet debugged as of date of this post);
- I encountered a weird bug in Swift 3 where the RMQChannel.direct() protocol methods are somehow being mistaken for methods named "dirent()" -- causing a compile error on all tests related to RMQ*Channel. This bug is reproducible even if I reduce the project to two 4-line files. I posted on the Apple Developer Forum about it; we'll see if anything comes of that.
Please add me to the list of developers interested in OSX support. Have a project that could use this immediately.
@electromaggot: Swift 3 tests are now in master. Tests on the osx branch are at least running on both OSX and iOS now. Remember to Cmd-Opt-Shift-K when switching platforms.
Some things I now know:
- We need to fix PKCS12 certificate handling for OSX
- We should fix the things that are deprecated in 10.12. Targeting 10.11 for now.
Sweet! THANKS Andrew!
FYI -- and I'm sure you already encountered this -- I hit a serious snag with Rabbit's direct() methods being renamed by the Obj-C/Swift bridging code. I tried posting a question about it on Apple's Dev Forum for Swift, but got snubbed by the "moderator." So I posted on StackOverflow, got some informative responses and a suggested fix. I filed a bug report with Apple. By no means is this acceptable: direct is not a reserved word, so to have #define direct dirent in the headers is outlandish.
@electromaggot: I can't reproduce that problem. testDirectDeclaresADirectExchange passes for me, even if I change it to use the 1-arity version of direct.
So I'm now in codesigning hell. Adding the framework on the osx branch to a Mac project results in code object is not signed at all errors. Anyone dealt with these before?
About codesigning: I ended up turning off codesigning for the whole application that was importing RMQClient, and the project built. This SO question has some useful information and links: http://stackoverflow.com/questions/17263967/codesign-of-dropbox-api-fails-in-xcode-4-6-3-code-object-is-not-signed-at-all
Available in master, we'd really appreciate community testing and feedback!
I want to use the lib to my mac OS app , but i found that it won't work ?
I am also finding this no longer works - has support been dropped accidentally/on purpose?
Ok so 0.10.0 will compile into a project if you remove #import <UIKit/UIKit.h> from RMQClient.h - though when you run it, the iOS framework linked (as recommended by your README.md), it does not run on OSX.
I've updated my Cartfile to 0.11.0 but I get a compilation error of "RMQClient/RMQConnection.h" was not found in RMQClient.h
I've looked in the framework and Current/Headers seems to include this file though..?
This image uses the 0.11.0 in Cartfile. I deleted the entire Carthage folder before running carthage bootstrap and used the Mac build version of the framework. But still get this:
