pod lib lint 将产物更新至私有库， i386 验证不通过问题讨论
Opened this issue · 7 comments
plugin 原生代码部分 无法依赖 到 flutter.framework 的头文件哦~~
部分版本的 CocoaPods 会出现 'Flutter/Flutter.h' file not found，该问题已经修复，请更新至最新代码🙂
我的意思是 lint不过的 不是podinstall
该次 commit b5262dc 就是解决的这个问题哈，多谢反馈🤝
只要依赖了 Flutter.framework 理论上就无法lint过了 因为lint 要检查i386架构，但是flutter.framework不支持i386
现在 Demo 里面随带的是 release 版本的产物，具体包含的架构细节如下，如果只是为了查看 Demo 效果，建议使用真机运行。
Flutter.framework/Flutter: Mach-O universal binary with 3 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
App.framework/App: Mach-O universal binary with 2 architectures: [arm_v7:Mach-O dynamically linked shared library arm_v7] [arm64]
这也只是个技术方案样例探讨~
实际开发过程中可以在类似于 YHFlutterSDK 对应的 pod 仓库内使用不同的分支来存储 debug 或者 release 版本的产物包，业务方自身选择性的生成更新并指向自己需要的，或者新创建一个单独维护自己业务线的 YHFlutterSDK 仓库都是可以的。
恩，感谢回复，按照你说的做的话，那主工程只能通过git地址加branch的方式 依赖 产物pod了，不能有效的进行版本管理。 我的想法是每次完成产物，把产物pod 推到私有仓库，主工程podfile直接版本号依赖就好。 现在是pod lib lint 一定会检查i386架构，所以一直过不去
OK，我们现在的使用方式就是【把产物 pod 推到私有仓库，主工程 podfile 直接版本号依赖】的方式，但是只有发版之后的稳定版本才会打 tag，那个验证不过的问题有下面几种策略可以屏蔽该验证，但也只限于这种纯产物库的修改，别的私有库建议还是要保证能够通过验证。
- 按照 pod 仓库的索引规则建立对应的目录结构和文件，git push 推上去即可；
- 自己创建一个新的 SDK 工程，把对应的调用接口的地方调整为空实现，然后自己生成一个 i386 的库（说白了就是个为了验证通过的空壳子而已），用 lipo 命令合并到对应的库中；
- 直接修改验证的 validator.rb 文件源码；