Skip to content
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

Impossible to use Swift version in iOS Framework #181

Closed
Jeehut opened this issue May 2, 2017 · 5 comments
Closed

Impossible to use Swift version in iOS Framework #181

Jeehut opened this issue May 2, 2017 · 5 comments

Comments

@Jeehut
Copy link

Jeehut commented May 2, 2017

Hello guys,

I just happened to add Carthage support for https://github.com/Daltron/NotificationBanner but ran into a problem: The project includes the Swift variant of this library, so I added the Swift library via Carthage, too. The problem is that the import statement when using Carthage looks like this:

import MarqueeLabelSwift

While the import of the Swift framework via CocoaPods still looks like the one in Objective C:

import MarqueeLabel

Could you please fix this issue in a way that this library can be referred to in another library that supports both CocoaPods AND Carthage? I think the easiest solution would be to rename the Swift framework to be included when using CocoaPods: Just name it MarqueeLabelSwift also and all should be fine.

Thanks in advance for your help!

@cbpowell
Copy link
Owner

cbpowell commented May 2, 2017

Actually in Cocoapods you would "select" the Swift version using pod 'MarqueeLabel/Swift', per the readme. That specifies the Swift subspec of the podspec (although true, the Objective-C is still the default if you do not specify a subspec).

So I totally haven't tried all these permutations lately, but I believe you can import Obj-C or Swift with Cocoapods OR Carthage using the methods in the below table? Asking for your feedback here, particularly on the Carthage side since I don't use it much, does any one of these definitely NOT work?

Lang Cocoapods Carthage
ObjC pod MarqueeLabel + #import "MarqueeLabel.h" github "cbpowell/MarqueeLabel" + #import <MarqueeLabel.h>
Swift pod MarqueeLabel/Swift + (no specific import required) github "cbpowell/MarqueeLabel" + import MarqueeLabelSwift

(There's also the tvOS version, but I left that out for simplicity)

@Jeehut
Copy link
Author

Jeehut commented May 10, 2017

Hi @cbpowell and sorry for letting you wait so long for an answer. I think I failed in explaining the issue well enough because you clearly misunderstood me. The thing is, that this library works in Apps via both CocoaPods and Carthage. But my goal was not to include it into an app, instead I tried to include it into a framework, namely into NotificationBanner.

The difference is: The frameworks, of course, also tries to be available to apps via both Carthage and CocoaPods. Now what THEY did before was to simply include this library via CocoaPods like this: pod MarqueeLabel/Swift. And as they were using the dynamic frameworks support in CocoaPods they needed to add import MarqueeLabel into their code.

Now that I added Carthage support the problem was that the import statement changed to import MarqueeLabelSwift. This doesn't compile any more for CocoaPods users (at least I don't think so) so I created this issue to get the import names of the Swift libraries alines in both CocoaPods and Carthage installation ways.

I hope this explains this issue.

Of course, maybe there's also a different way of fixing this, but what I need is a solution to support both CocoaPods and Carthage in framework projects when including this library. Feel free to checkout my PR there which adds support for Carthage in that project. It works perfectly fine via Carthage with my changes, but my best guess is that it's going to break the framework for CocoaPods users.

@cbpowell
Copy link
Owner

Ah, understood! Yeah I totally missed that, but I see what you mean now.

I'll have to think about it and try a few things - the simplest approach of renaming might have more impacts to Cocoapods users than I'd prefer. It's unfortunate that Carthage doesn't seem to support building only specific targets/frameworks, and they seem against adding that functionality.

I haven't had a chance to try it, but I think Carthage does add an environment variable to the build letting you know it's being built with Carthage? I'm thinking that could be used in a macro of sorts to switch the import statement. Not the cleanest, I know, but also not too much impact.

@cbpowell
Copy link
Owner

@Dschee @Daltron So I don't see a great way around this that doesn't cause headaches for current MarqueeLabel users and/or myself. I could:

  1. Split the podspec into two separate specs, one for Obj-C and one for Swift (ironically that's how it used to be). However I pretty much consider Swift to be "the future" so I'd actually be inclined to make the Swift version have the base "MarqueeLabel" name. The downside is this would drive a major version number change for naming only, and I don't think I want to do that right now.

  2. Create a podspec called MarqueeLabelSwift that's basically only for people who need Cocoapods+Carthage compatibility in their released frameworks. This wouldn't be too hard, and it would basically only have an impact on me - I'd just need to keep that separate spec also up to date when releasing new versions. Or this new spec could pull MarqueeLabel/Swift without a version specified, thereby always getting the latest version (pro: no additional maintenance work for me).

Alternatively, people using this framework can work around the issue with a fairly small change. See my pull request to @Dschee's branch which would be a quick/immediate fix. It works by adding a CARTHAGE_CONFIG custom Swift complier flag, and the revised code then checks if that flag is set when making the import statement. It feels a little clunky, but there's actually an accepted Swift proposal in work to allow checking of module availability which would make it a little cleaner in the future.

What do you guys think?

@cbpowell
Copy link
Owner

cbpowell commented Jun 8, 2017

I've added a note to the README about this topic, so I'll go ahead and close this - BUT, I'm going to keep it in mind for the future because I don't think this is the optimum solution.

@cbpowell cbpowell closed this as completed Jun 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants