Create Xcode project with shared framework schemes for Carthage support

[Jeehut]

@mw99 Thank you for sharing this great library, much appreciated! ありがとうございます！

I've just added support for installation via Carthage, an alternative to CocoaPods. I think more people will be able to use your library once Carthage support is merged. Basically to support Carthage one just needs a project with shared framework targets, which I added. In case you add more Swift files, you just need to add them to the Xcode project, too, in order to keep support for Carthage. No release steps needed, Carthage automatically uses GitHub tags, so tagging should suffice. If you want a released version supporting Carthage, just tag your master branch with version 3.0.1 after merging this.

Schönen Gruß eines Japan-Interessierten aus Karlsruhe! 🇯🇵 😉

[mw99]

Sorry for the way to late reply. I kinda forgot about this. There is no way to support Carthage without adding a whole Xcode project?

Beste Grüße zurück

[Jeehut]

That is exactly right. Carthage builds a shared scheme within an Xcode project using the command line tools of Xcode. This requires an Xcode project which also can't be generated when needed automatically as of now with the likes of SwiftPM, maybe sometime in the future.

[mw99]

Actually the swift package manager can generate a Xcode project with:

$ swift package generate-xcodeproj

In my opinion Carthage should somehow be able to do this on it's own when it depends on Xcode projects. That way all swift package manager packages would be compatible to Carthage without me doing anything 😄 Maybe I'm not seeing the whole picture here, but wouldn't that the way to go?

[Jeehut]

Carthage doesn't support such a thing and probably never will (it takes years for them to even answer when it comes to features everybody needs but the maintainers themselves don't, see here for example). It really isn't worth arguing with them or waiting for such a thing.

Also, there are features within Xcode that can't be described within SwiftPM's manifest file, like resource inclusion. Your project doesn't need that, but for this simple reason alone will the Carthage maintainers as I have come to know them never agree to incorporate no-project SwiftPM packages support. I've actually started building a new package manager, that exactly solves these problems of Carthage and will be able to incoporate both Carthage compatible projects as well as SwiftPM compatible projects. But that's "Zukunftsmusik", to put it in a German word. Currently I'm not working on it so it might take until summer until it's ready to use.

So the question here is basically, do you want to support Carthage users or not. Cause if you want, there's currently no other way and although I understand it doesn't feel like a pretty thing to do, I tried to make very clear that the project is only there for Carthage supporting purposes and also put the project into a sub directory so people don't accidentally open it when developing. If you want, you can add a section in the README how contributos can develop in this project, but SwiftPM developers should already know so that shouldn't be a problem.

[mw99]

Oh man I read that thread. Classic github drama. Seeing that does not but a lot of confidence in the future of Carthage. I used Carthage same years ago. I don't remember exactly why, but it felt to rigid and had too much limitations. Configuration options lacking everywhere. So I ditched it.

So the question here is basically, do you want to support Carthage users or not.

That thread and my own Carthage experiences are both rather negative. Besides that, I do want to keep this as simple as possible here. This is a very simple library but for a release I already have to test different versions for:

• Swift
• SPM
• Xcode
• Cocoa Pods And I'm glad I can do this without Xcode project files which have versioning on their own. Also I don't want user to get the impression that Xcode project files are needed. Because they are not. Therefore, sorry, no Carthage support.

If you want, you can add a section in the README how contributos can develop in this project

Will think about that.

I've actually started building a new package manager, that exactly solves these problems of Carthage

Ambitious project. Good luck

[Jeehut]

Oh, I was not expecting that you actually consider neglecting Carthage support. Just to give you some additional motivation:

1. You don't need to do anything in the Xcode project. No versioning, nothing. Only if new Swift files were added, you would need to link them in the Xcode project, too. But if you forget it, then only Carthage support would be broken and I would probably just add it via a new PR. So no worries.

2. To be clear, I don't dislike Carthage and I think Carthage is still the best package manager for many iOS projects. I just don't think you should wait for them to finish any feature you might think they should implement. They won't. But neglecting it entirely (especially given that I did all the hard work) would simply mean that you're not taking the Swift community seriously and might piss off many developers who might otherwise have used this great library.

3. By not merging this, you're only keeping the repo "as simple as possible" for yourself, but not for the many Carthage users. And as I stated in (1) you don't need to worry about "complexity" for yourself as there's really nothing you need to do to conform to Cartahge, even if you make new releases. It will magically work (that's actually one of the advantages of Carthage compared to CocoaPods).

Regarding the future of Carthage, I don't think it's going to be around once SwiftPM is integrated with Xcode, but that'll take until late 2020, which is still many many months to go where people could use your library.

I hope I could convince you to merge this. You can think of it this way: If you have Carthage support, your library is more likely to gain stars than if it doesn't. ;-)

[mw99]

So played a bit with swift package generate-xcodeproj and Carthage and had quite successful results. A generated project basically worked out of the box which surprised me. I just released version 3.3.0 which should have working Carthage support. However only for Swift 5 (needs current Xcode 10.2 beta). I don't plan to back port this, so you may can't use it right away.

Why I'm not merging your pull request and added my own files: I like the idea of just regenerating. I just run swift package generate-xcodeproj --output CarthageSupport and everything should work again should future versions of Swift/Xcode break Carthage support. But thanks man.

Drop me a line if you ever come to Tokyo.

[Jeehut]

Oh, it seems they finally did make some useful progress over there and now support building SwiftPM based projects. Must be a younger addition to Carthage, cause I didn't know about that. Only supporting Swift 5 is fine with me as my intention was future-oriented anyways, shouldn't take long until Swift 5 stable release is fainally here. :)

Thanks for testing this and making it work! I also just dropped you an email regarding when I'll be in Tokyo.

[Jeehut]

Oh, I had misunderstood you the whole time, but I just had a look at the commit and now I understand. 🤣

Of course this works, I thought you were looking for a solution where Carthage would run swift package generate-xcodeproj for you so you don't have to add an Xcode project to the repo. Also I thought Carthage has added that feature in the meantime, but of course they haven't. 😓

You're right that this is a cleaner solution than what I did. I hope it works for all targets (iOS, tvOS, macOS & watchOS) and that it doesn't make any problems when doing an archive and trying to release that. But we'll find out eventually. :)