search

ibireme / YYWebImage

Asynchronous image loading framework.
MIT License
3.56k stars 615 forks source link

安装了YYCategories，YYCache，YYModel，YYText，YYImage，用CocoaPods安装YYWebImage时候提示冲突。 #25

Closed pandaBilbo closed 8 years ago

pandaBilbo commented 8 years ago

错误信息： The 'Pods' target has frameworks with conflicting names: WebP.

ibireme commented 8 years ago

Readme 里有提到：YYWebImage 底层用 YYCache 实现了内存和磁盘缓存, 用 YYImage 实现了 WebP/APNG/GIF 动图的解码和播放。

所以，如果导入了 YYWebImage，那就可以把 YYImage 和 YYCache 去掉了~

skyline75489 commented 8 years ago

感觉这种隐式的库依赖不是特别好吧，能不能在 Podspec 里显式加入对于 YYImage 和 YYCache 的依赖，这样依赖关系更清晰一点，也避免了 YYImage 和 YYCache 的更新还要手动同步到这个库里来

ibireme commented 8 years ago

主要是我希望别人下载代码下来后，直接就能编译和使用，也能方便调试。 YYImage 和 YYCache 的更新，我会同步到这边来，使用者可以不用关心。

不过，这么做依赖关系确实不太好看。。

skyline75489 commented 8 years ago

这个库本身编译不编译关系到不大吧，毕竟大家基本都是用 pod 来用的。好多开源项目都是 clone 之后还要再 pod install 或者 git submodule update 才能编译过的，刚开始我也感觉很不方便，后来自己也习惯了……

ibireme commented 8 years ago

我经常看各种 iOS 的开源项目，有时我只是想尽快看看 Demo 的实际效果，这时 pod 或 submodule 会非常啰嗦。。网速慢时就更是让人头疼了。。太浪费时间。。

skyline75489 commented 8 years ago

+1，确实很多项目要再用 pod 和 submodule 安装依赖会很不爽，但是隐式地引入别的库依赖也不是很好，特别是 WebP，我看有好多人报 issue 说冲突了。

能不能这样，把 YYCache 和 WebP 这些依赖挪到 Demo 工程里去，然后在 Podspec 里不包含这些库的源文件，而是写成 dependency。这样 clone 下来 Demo 依然可以直接跑，通过 Pod 安装也不会报冲突了。

ibireme commented 8 years ago

YYCache 可以这样挪走。

YYImage 和 WebP 这个比较特殊，CocoaPods 里的 WebP 库，都是用默认编译参数编译的，没有 mux/demux 模块，这样即使引入了进来，也无法在支持动画 WebP 图片。如果使用者没处理好这个地方，会产生 “已经引用了 WebP 库但是还是不能解码 WebP 啊” 这样的问题。

另外，YYImage 判断是否启用 WebP，是在编译时通过 #if __has_include(xxx.h) 这种方式判断的，我不太确定 pod 编译时是否会有问题。

稍后我会尝试处理一下这块儿，看看怎样能处理得更好一些，感谢提供建议~

skyline75489 commented 8 years ago

WebP 这个我倒是真没想到。我刚搜了一下，原来谷歌做了源码的 WebP 的 spec，之所以大家都还在用 Framework 的版本，大概是因为它里面引用的源码地址是谷歌的，直接就被墙了。。。

fjarcticfox commented 8 years ago

最好还是分开吧，pod 已经很普遍了。

PrideChung commented 8 years ago

+1 建议分开 我之前用pod引入了 YYCache，最近又引入了 YYWebImage，结果编译的时候出现了duplicated declaration，开始还以为有什么编译缓存没清干净，仔细看才发现居然真的是引入两份YYCache的代码