Carthage installation not working

[bpoplauschi]

Since there is no shared scheme for building the framework, we get this error when trying to install via Carthage:

Dependency "SDWebImageFLPlugin" has no shared framework schemes for any of the platforms: iOS

Cartfile:

github "SDWebImage/SDWebImageFLPlugin" "master"

Command

carthage update --platform ios --configuration DEBUG

[dreampiggy]

Because this repo I create, using the pod lib create with https://github.com/CocoaPods/pod-template. It supports Carthage by default. However, the cost is that, you should add the Example/Pods folder into git verson control. Which Carthage can download your repo with full the source code and build the Pods project successfully.

However, I disable this Example folder in the gitignore. So that carthage checkout will not contains any actual Xcode project and source code for dependency. Well, I can simply remove that gitignore, and everything works.

I think adding Example/Pods into git repo, contains other dependency code (Currentlly is SDWebImage, FLAnimatedImage, Expecta), it's not always a good idea. This may cause our git repo become larger, and even cause merge conflict, if we have multiple branches and each branch use its own Podfile for Example project.

I search the result, but it seems that I have to create a standalone Xcode project for the framework itself. It's just a simple wrapper Xcode project. And I can use Cartfile to download the depedency and can also ignore them into .gitignore.

I'll create a PR soon.

[bpoplauschi]

Thanks for doing this @dreampiggy. I will do the same for SDWebImage/SDWebImageWebPCoder#1 - this is how I noticed the problem

[bpoplauschi]

I can confirm it works now, just tried again (with master branch) and everything builds ok. ☀️

[dreampiggy]

@bpoplauschi Actually, if you're lazy and don't mind that Example/Pods commit into the repo. You can just use pod lib create without adding that folder into gitignore. Then all things done because that _Pods.xcodeproj actually point to the development pod. So that when carthage update, the example folder with dependency source code was downloaded and can successfully build.

But I don't like that way :) Which will mass up our source code repo. But it's just a personal taste. For example, if you want to make SDWebImageWebPCoder compatible for Carthage, you can keep the Example/Pods folder, and bind webp using git submodule, so you don't need to create something like that SDWebImage/libwebp-Xcode

So actually, it depends. These two solutions. And I prefer the second one. 😅

[bpoplauschi]

@dreampiggy Thanks for the extra details.
I also don't like the idea of using Pods.xcodeproj as the project that generates the scheme which Carthage will use :)
I will implement a similar approach to this one: just create an Xcode project and a shared scheme for SDImageWebPCoder.

Regarding the solution I decided to use for the libwebp dependencies:

• the official libwebp repo does not have CocoaPods or Carthage support. Since CocoaPods support can be added directly to CocoaPods-Trunk (actually in their Specs repo), I have done that some time ago. Carthage was still missing
• I created SDWebImage/libwebp-Xcode exactly for this purpose, to just add an Xcode project to the source code they already provide. That is why this repo uses libwebp as a submodule.
  • the use cases of this repo are not limited to Carthage support for libwebp or our project.
  • since I do most of the libwebp publishing to CocoaPods, I can also do it in this repo for Carthage
• SDWebImage/SDImageWebPCoder is on the next abstraction level. It doesn't care about where libwebp comes or if it has an Xcode project or not. Using SDWebImage/libwebp-Xcode, SDImageWebPCoder can also be installed via Carthage.
• I think it's important for us to keep consistent across our repos. If we want to support a feature (in this case installation via Carthage), we need it in all the repos. Otherwise it's weird the Core library has it and the extensions don't, so people can't really be flexible. I will make sure all our plugins support this

[dreampiggy]

@bpoplauschi I agree this approach. That SDWebImage/libwebp-Xcode may become the same thing for Carthage, like libwebp on Cocoapods.

And, do we need to provide some other repos in SDWebImage organization with full carthage support ? Maybe I need to add them one by one 😅 Not hard, just need some times...And most of them are all Apple platform compatible (iOS / macOS / watchOS / tvOS), I need to add 4 schemes for each wrapper Xcode project.

[dreampiggy]

@bpoplauschi One little issue. Do we need to rename the coder plugin repo's coder class name, to the naming without that Web?

For example, the SDWebImageWebPCoder repo, has one class named SDImageWebPCoder. Do we need to use this naming without Web ? Or keep using Web like the other repo such as SDWebImageHEIFCoder with SDWebImageHEIFCoder class naming ?

[bpoplauschi]

@dreampiggy I just renamed the repo from SDImageWebPCoder to SDWebImageWebPCoder. I would not rename the class since we already need a SDWebImageWebPCoder.h to act as a framework header different from SDImageWebPCoder.h which contains the actual definition of the coder. - stay tuned

[dreampiggy]

If so, I'll later renaming all other custom coder repo, including HEIF BPG coder. The coder class name should be without that Web prefix. But the repo name keep that Web prefix. Each repo's umbrella header name should be equal to the repo name.

[bpoplauschi]

Hmm. I don't understand :)
I just added the Web prefix to the repo name, why you want to remove it from the others?

[dreampiggy]

@bpoplauschi To keep the naming consistently...

For example, current all our plugin coders (including the coders in the SDWebImage/Core), will looks like these:
[SDImageIOCoder, SDImageGIFCoder, SDImageAPNGCoder, SDImageWebPCoder, SDWebImageHEIFCoder, SDWebImageBPGCoder].

I think, we can just name these all like SDImageXXXXCoder...So I can start to change the last two with the correct naming SDImageHEIFCoder && SDImageBPGCoder. The coder plugin repo name is kept without changes.

[bpoplauschi]

Oh, got it. Sounds good. For consistency using SDWebImage prefix just for the repo name and SDImageXXXXCoder for the actual coder class. Totally agree