pod bin archive时找不到私有源依赖

njuxjy commented 5 years ago

如果podspec中依赖的pod属于私有spec源，那么在pod bin archive时会报错：

Unable to find a specification for XXXX depended upon by YYY

包括pod bin spec lint和pod bin repo push等都有这个问题。

能否像cocoapods-packager那样提供 --spec-sources选项来指定私有源？

tripleCC commented 5 years ago

是存在多个私有源么？目前插件 pod bin spec lint和pod bin repo push包含了 pod spec lint 和 pod repo push 的 options，可以通过 --sources=A,B 来指定除了 bin.yml 配置文件两个私有源外的额外的源

pod bin archive 我也加下好了

njuxjy commented 5 years ago

嗯，确实存在多个私有源。嗯，archive最好也能加下，不然只能用pod packager打包了

tripleCC commented 5 years ago

已经发布了不过感觉多个私有源不方便，源码一个，二进制一个差不多了，不清楚你是什么样的场景

njuxjy commented 5 years ago

感谢。历史原因，公司内部时间长了以后不同组各自可能都维护了自己的私有源，依赖多个组的组件就指定了多个私有源

tripleCC commented 5 years ago

这种情况下，如果你用到了插件切换二进制、源码，可能会有问题因为插件目前只能设置一个源码私有源和一个二进制私有源，如果在 bin.yml 里面的源码私有源里面不包含某个组件，而是在外部加的源里面，插件就不知道这个源是源码的还是二进制的了。

tripleCC commented 5 years ago

其实我感觉如果有权限的话，把源码私有源统一到一个仓库对以后也挺有帮助的，包括统一分析组件什么的。可以新建一个仓库，然后给其他私有源仓库加 webhook ，把其他私有源的更新都同步到这个仓库里面。插件里面有一些命令都是基于每种类型的源只有一个的基础上，去做减少输入参数处理的。比如 pod bin repo push ，就是直接推送到 bin.yml 里面的源码私有源，这个命令没有加推送到指定私有源的 option

njuxjy commented 5 years ago

这种情况下，如果你用到了插件切换二进制、源码，可能会有问题因为插件目前只能设置一个源码私有源和一个二进制私有源，如果在 bin.yml 里面的源码私有源里面不包含某个组件，而是在外部加的源里面，插件就不知道这个源是源码的还是二进制的了。

这两天在把一个复杂组件二进制化，趟坑中，完了以后会试下源码和二进制化切换，看看会不会有什么问题

njuxjy commented 5 years ago

其实我感觉如果有权限的话，把源码私有源统一到一个仓库对以后也挺有帮助的，包括统一分析组件什么的。可以新建一个仓库，然后给其他私有源仓库加 webhook ，把其他私有源的更新都同步到这个仓库里面。插件里面有一些命令都是基于每种类型的源只有一个的基础上，去做减少输入参数处理的。比如 pod bin repo push ，就是直接推送到 bin.yml 里面的源码私有源，这个命令没有加推送到指定私有源的 option

权限没什么问题。你说的这个倒也可以考虑，不过目前牵涉面有点大，不同业务之间会交叉依赖一些私有源，改动起来还是有一定成本。万不得已下再尝试下

tripleCC commented 5 years ago

其实我感觉如果有权限的话，把源码私有源统一到一个仓库对以后也挺有帮助的，包括统一分析组件什么的。可以新建一个仓库，然后给其他私有源仓库加 webhook ，把其他私有源的更新都同步到这个仓库里面。插件里面有一些命令都是基于每种类型的源只有一个的基础上，去做减少输入参数处理的。比如 pod bin repo push ，就是直接推送到 bin.yml 里面的源码私有源，这个命令没有加推送到指定私有源的 option

权限没什么问题。你说的这个倒也可以考虑，不过目前牵涉面有点大，不同业务之间会交叉依赖一些私有源，改动起来还是有一定成本。万不得已下再尝试下

个人感觉私有源只是指明了组件的搜索入口，只要组件的 podspec 一样，业务组的私有源和新增的统一私有源可以同时存在，最终决定用哪个私有源是 Podfile 决定的，也就是说成本应该只有新增私有源仓库，同步 podspec 这两个，业务组想用哪个源都可以，不影响业务组现有的依赖关系，最终也可以慢慢过渡到新增的统一私有源。

感觉业务之间会交叉依赖一些私有源并不影响私有源的统一，不知道你的实际情况如何，我这边虽然没有遇到你这种需要统一私有源的情况，不过给私有源仓库添加 webhook，然后把组件信息同步到数据库这一步还是有做的，如果只是这个，webhook 会带回完整的增删改信息，通过 gitlab api 获取业务源的 podspec 文件，再通过 gitlab api 同步到新增仓库中，只要有个简单的 web 服务器就行

njuxjy commented 5 years ago

这种情况下，如果你用到了插件切换二进制、源码，可能会有问题因为插件目前只能设置一个源码私有源和一个二进制私有源，如果在 bin.yml 里面的源码私有源里面不包含某个组件，而是在外部加的源里面，插件就不知道这个源是源码的还是二进制的了。

我现在遇到个问题，不知道和你说的这个有没有关系。

环境： cocoapods 1.7.5 pod bin init设置的源码私有源地址：git@gitlab.xxx.com:iOS/Specs1.git pod bin init设置的二进制私有源地址：git@gitlab.xxx.com:iOS/BinarySpecs.git Podfile:

# 私有source spec repo 1
source 'git@gitlab.xxx.com:iOS/Specs1.git'
# 私有source spec repo 2
source 'git@gitlab.xxx.com:iOS/Specs2.git'
# 私有source spec repo 3
source 'git@gitlab.xxx.com:iOS/Specs3.git'
# 私有source spec repo 4
source 'git@gitlab.xxx.com:iOS/Specs4.git'

install! 'cocoapods',
          generate_multiple_pod_projects: true,
          disable_input_output_paths: true,
          incremental_installation: true

plugin 'cocoapods-bin'
use_binaries!

有两个Pod, PodA依赖PodB，PodA中用尖括号方式import PodB中头文件:

#import <PodB/PodB.h>

PodA和PodB的spec都在源码私有源 git@gitlab.xxx.com:iOS/Specs1.git 中。

情况一：PodA和PodB都采用源码版本，相应的Podfile:

use_binaries!
set_use_source_pods ['PodA', 'PodB']

这种情况可以正常编译

情况二：PodA采用源码版本，PodB采用二进制版本，相应的Podfile:

use_binaries!
set_use_source_pods ['PodA']

这种情况无法正常编译，在PodA import PodB头文件的地方报 <PodB/PodB.h> 头文件找不到。

不知道作者有没遇到过这情况

njuxjy commented 5 years ago

其实我感觉如果有权限的话，把源码私有源统一到一个仓库对以后也挺有帮助的，包括统一分析组件什么的。可以新建一个仓库，然后给其他私有源仓库加 webhook ，把其他私有源的更新都同步到这个仓库里面。插件里面有一些命令都是基于每种类型的源只有一个的基础上，去做减少输入参数处理的。比如 pod bin repo push ，就是直接推送到 bin.yml 里面的源码私有源，这个命令没有加推送到指定私有源的 option

权限没什么问题。你说的这个倒也可以考虑，不过目前牵涉面有点大，不同业务之间会交叉依赖一些私有源，改动起来还是有一定成本。万不得已下再尝试下

个人感觉私有源只是指明了组件的搜索入口，只要组件的 podspec 一样，业务组的私有源和新增的统一私有源可以同时存在，最终决定用哪个私有源是 Podfile 决定的，也就是说成本应该只有新增私有源仓库，同步 podspec 这两个，业务组想用哪个源都可以，不影响业务组现有的依赖关系，最终也可以慢慢过渡到新增的统一私有源。

感觉业务之间会交叉依赖一些私有源并不影响私有源的统一，不知道你的实际情况如何，我这边虽然没有遇到你这种需要统一私有源的情况，不过给私有源仓库添加 webhook，然后把组件信息同步到数据库这一步还是有做的，如果只是这个，webhook 会带回完整的增删改信息，通过 gitlab api 获取业务源的 podspec 文件，再通过 gitlab api 同步到新增仓库中，只要有个简单的 web 服务器就行

感觉确实能做，从单一私有源拉取也比较干净。内部现有的私有源较多，按业务和用途切分：

git@gitlab.xxx.com:Mirrors/Specs.git // github第三方依赖镜像
git@gitlab.xxx.com:BusinessA/Specs.git // 业务部门A私有源
git@gitlab.xxx.com:BusinessB/Specs.git // 业务部门B私有源 ....
git@gitlab.xxx.com:BusinessX/Specs.git // 业务部门X私有源

技术上迁移问题不大，推动业务部门去用统一的源需要花点力气。业务都是倾向于稳定，没事都懒得改动。如果不用统一的私有源也能实现组件二进制，业务就倾向于保持不变。不过试下来多个私有源可能确实有些问题，比如我上个回复中提到的那个问题。

njuxjy commented 5 years ago

这种情况下，如果你用到了插件切换二进制、源码，可能会有问题因为插件目前只能设置一个源码私有源和一个二进制私有源，如果在 bin.yml 里面的源码私有源里面不包含某个组件，而是在外部加的源里面，插件就不知道这个源是源码的还是二进制的了。

我现在遇到个问题，不知道和你说的这个有没有关系。

环境： cocoapods 1.7.5 pod bin init设置的源码私有源地址：git@gitlab.xxx.com:iOS/Specs1.git pod bin init设置的二进制私有源地址：git@gitlab.xxx.com:iOS/BinarySpecs.git Podfile:
# 私有source spec repo 1
source 'git@gitlab.xxx.com:iOS/Specs1.git'
# 私有source spec repo 2
source 'git@gitlab.xxx.com:iOS/Specs2.git'
# 私有source spec repo 3
source 'git@gitlab.xxx.com:iOS/Specs3.git'
# 私有source spec repo 4
source 'git@gitlab.xxx.com:iOS/Specs4.git'

install! 'cocoapods',
          generate_multiple_pod_projects: true,
          disable_input_output_paths: true,
          incremental_installation: true

plugin 'cocoapods-bin'
use_binaries!
有两个Pod, PodA依赖PodB，PodA中用尖括号方式import PodB中头文件:
#import <PodB/PodB.h>
PodA和PodB的spec都在源码私有源 git@gitlab.xxx.com:iOS/Specs1.git 中。

情况一：PodA和PodB都采用源码版本，相应的Podfile:
use_binaries!
set_use_source_pods ['PodA', 'PodB']
这种情况可以正常编译

情况二：PodA采用源码版本，PodB采用二进制版本，相应的Podfile:
use_binaries!
set_use_source_pods ['PodA']
这种情况无法正常编译，在PodA import PodB头文件的地方报 <PodB/PodB.h> 头文件找不到。

不知道作者有没遇到过这情况

找到个临时解决办法，当PodA采用源码版本，PodB采用二进制版本时，pod install后去Pods-> PodA的build settings中的framework search paths中加上"${PODS_ROOT}/PodB" 就能编译了。

这块不知道插件能否自动处理下

tripleCC commented 5 years ago

这种情况下，如果你用到了插件切换二进制、源码，可能会有问题因为插件目前只能设置一个源码私有源和一个二进制私有源，如果在 bin.yml 里面的源码私有源里面不包含某个组件，而是在外部加的源里面，插件就不知道这个源是源码的还是二进制的了。

我现在遇到个问题，不知道和你说的这个有没有关系。

环境： cocoapods 1.7.5 pod bin init设置的源码私有源地址：git@gitlab.xxx.com:iOS/Specs1.git pod bin init设置的二进制私有源地址：git@gitlab.xxx.com:iOS/BinarySpecs.git Podfile:
# 私有source spec repo 1
source 'git@gitlab.xxx.com:iOS/Specs1.git'
# 私有source spec repo 2
source 'git@gitlab.xxx.com:iOS/Specs2.git'
# 私有source spec repo 3
source 'git@gitlab.xxx.com:iOS/Specs3.git'
# 私有source spec repo 4
source 'git@gitlab.xxx.com:iOS/Specs4.git'

install! 'cocoapods',
          generate_multiple_pod_projects: true,
          disable_input_output_paths: true,
          incremental_installation: true

plugin 'cocoapods-bin'
use_binaries!
有两个Pod, PodA依赖PodB，PodA中用尖括号方式import PodB中头文件:
#import <PodB/PodB.h>
PodA和PodB的spec都在源码私有源 git@gitlab.xxx.com:iOS/Specs1.git 中。

情况一：PodA和PodB都采用源码版本，相应的Podfile:
use_binaries!
set_use_source_pods ['PodA', 'PodB']
这种情况可以正常编译

情况二：PodA采用源码版本，PodB采用二进制版本，相应的Podfile:
use_binaries!
set_use_source_pods ['PodA']
这种情况无法正常编译，在PodA import PodB头文件的地方报 <PodB/PodB.h> 头文件找不到。

不知道作者有没遇到过这情况

https://github.com/CocoaPods/CocoaPods/issues/8668 这个问题可以看这里，暂时没解决

tripleCC commented 5 years ago

这里看错了，你遇到的问题和 CocoaPods/CocoaPods#8668 不一样。 PodA 依赖 PodB ，PodB 使用二进制版本，如果 PodB 存在 modulemap 文件，并且文件暴露了 PodB.h 那么 PodA 可以引用 <PodB/PodB.h> 。插件生成 modulemap 策略沿用了 cocoapods-packager，有三种情况：

如果工程里面有 modulemap，那么就用现有的；
如果工程里面没有 modulemap，但是存在和工程同名的伞头文件，PodB.h ，那么生成 modulemap 导出这个伞头文件。
如果工程里面都没有上面的文件，生成的 framework 不会包含 modulemap。所以可能出现你说的，#import <PodB/PodB.h> 的时候报错。

tripleCC commented 5 years ago

还有，如果 PodA 依赖了 PodB ，那么生成 PodA.xcconfig 会自动包含你说的那个配置：

FRAMEWORK_SEARCH_PATHS = $(inherited) "${PODS_ROOT}/PodB"

这边的 cocoapods 版本是 1.7.5 ，并没有开启 generate_multiple_pod_projects ，可能和这个也有关系，我遇到这种情况，一般都是原组件的二进制版本 modulemap 未生成，其他的原因暂时没有遇到过

tripleCC commented 5 years ago

我试了内部工程的 generate_multiple_pod_projects ，打开之后，编译依然没问题

njuxjy commented 5 years ago

试了一把：

给PodB增加了伞头文件，archive后确认framework中包含了modulemap，PodB发布新版本
PodA采用源码，PodB采用二进制，pod install
查看PodA.xcconfig，FRAMEWORK_SEARCH_PATHS中仍然没有PodB，但是存在那些不由插件管理的静态库依赖
编译还是头文件找不到错误

对比了下PodA和PodB均采用二进制的情况：

查看PodA.xcconfig，FRAMEWORK_SEARCH_PATHS中存在PodB，也存在不由插件管理的静态库依赖
编译没问题

附上PodA采用源码时的Podfile:

plugin 'cocoapods-bin'
use_binaries!
set_use_source_pods ['PodA']

install! 'cocoapods',
          generate_multiple_pod_projects: true,
          disable_input_output_paths: true,
          incremental_installation: true

njuxjy commented 5 years ago

感觉在生成PodA.xcconfig的时候把PodB当成源码依赖了，没放入FRAMEWORK_SEARCH_PATHS中

tripleCC commented 5 years ago

我这边并没有这个问题，比如我们的 Networking 框架，依赖 AFNetworking，Networking 用源码，AFNetworking 用二进制，FRAMEWORK_SEARCH_PATHS 就有依赖的所有 framework

FRAMEWORK_SEARCH_PATHS = $(inherited) "${PODS_ROOT}/AFNetworking"

https://github.com/for-example-test/cocoapods-bin-issue-11-import 你可以用这个工程试试看

njuxjy commented 5 years ago

跑了你的工程，都是OK的。

最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。

当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。

非常感谢

njuxjy commented 5 years ago

另外 CocoaPods/CocoaPods#8668 这个问题我之前也遇到过，我的临时解决办法是打完framework后把里面的Modules文件夹删除，SO上有人也这么做 https://stackoverflow.com/questions/38423565/include-of-non-modular-header-inside-framework-module-error

tripleCC commented 5 years ago

跑了你的工程，都是OK的。

最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。

当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。

非常感谢

跑了你的工程，都是OK的。

最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。

当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。

非常感谢

如果 PodA 能把 subspec 铺平是最好的了，直接用插件生成，这样就不用模版 podspec。subspec 这东西，感觉很多时候比较鸡肋，会极大地增加 lint 耗时，即使改其中一个 subspec，还是需要对这个组件的所有 subspec 以及自身走 lint ，我们这边是把原来大部分 subspec 都拆成独立的工程了

tripleCC commented 5 years ago

另外 CocoaPods/CocoaPods#8668 这个问题我之前也遇到过，我的临时解决办法是打完framework后把里面的Modules文件夹删除，SO上有人也这么做 https://stackoverflow.com/questions/38423565/include-of-non-modular-header-inside-framework-module-error

这么做的话就没有 moudlemap 文件了把，感觉这个文件还是需要的，能避免很多规范性问题

njuxjy commented 5 years ago

跑了你的工程，都是OK的。最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。非常感谢

跑了你的工程，都是OK的。最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。非常感谢

如果 PodA 能把 subspec 铺平是最好的了，直接用插件生成，这样就不用模版 podspec。subspec 这东西，感觉很多时候比较鸡肋，会极大地增加 lint 耗时，即使改其中一个 subspec，还是需要对这个组件的所有 subspec 以及自身走 lint ，我们这边是把原来大部分 subspec 都拆成独立的工程了

我们PodA是个基础业务组件，用subspec主要用来切分resource，不同业务部门需要不同的resource就接不同的subspec，避免接入全量resource造成浪费。代码都是一套，所以我们的情况用subspec应该还好。

我们这有些部门会对外输出一些能力，以单一Pod的形式输出比较方便接入方。这是个大而全的Pod，里面有很多子业务模块，都会频繁更新，都拆成独立Pod的话发版有点太频繁，依赖管理也有点麻烦，权衡下来他们都放一个Pod里，用subspec来切，有点mono repo的意思。然后不同subspec里定义不同的宏，接入方接入自己需要的subspec，其余subspec的代码不会参与编译。估计跟你那边情况不完全一样。

njuxjy commented 5 years ago

另外 CocoaPods/CocoaPods#8668 这个问题我之前也遇到过，我的临时解决办法是打完framework后把里面的Modules文件夹删除，SO上有人也这么做 https://stackoverflow.com/questions/38423565/include-of-non-modular-header-inside-framework-module-error

这么做的话就没有 moudlemap 文件了把，感觉这个文件还是需要的，能避免很多规范性问题

确实是把modulemap删了。暂时只能先删了，不然编译不过。回头再来查下是不是里面有些隐藏的小问题引起的。

tripleCC commented 5 years ago

跑了你的工程，都是OK的。最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。非常感谢

跑了你的工程，都是OK的。最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。非常感谢

如果 PodA 能把 subspec 铺平是最好的了，直接用插件生成，这样就不用模版 podspec。subspec 这东西，感觉很多时候比较鸡肋，会极大地增加 lint 耗时，即使改其中一个 subspec，还是需要对这个组件的所有 subspec 以及自身走 lint ，我们这边是把原来大部分 subspec 都拆成独立的工程了

我们PodA是个基础业务组件，用subspec主要用来切分resource，不同业务部门需要不同的resource就接不同的subspec，避免接入全量resource造成浪费。代码都是一套，所以我们的情况用subspec应该还好。

我们这有些部门会对外输出一些能力，以单一Pod的形式输出比较方便接入方。这是个大而全的Pod，里面有很多子业务模块，都会频繁更新，都拆成独立Pod的话发版有点太频繁，依赖管理也有点麻烦，权衡下来他们都放一个Pod里，用subspec来切，有点mono repo的意思。然后不同subspec里定义不同的宏，接入方接入自己需要的subspec，其余subspec的代码不会参与编译。估计跟你那边情况不完全一样。

我的意思是这个发布这个大而全的 Pod 很耗时间。我们这边也会有对其他业务组输出业务组件的场景，基本上会创建一个壳组件，这个组件再设置所有输出的组件，外界依赖这个壳组件。好处是，假如我们有三个组件 A，B，C，这次只改了 C ，那么我只发布 C 就可以了，整个 CI 的 pipeline 很短，这对于动则15+个组件的发布来说，还是比较关键的，而且开发时只更改 C 壳工程即可，不用在意 A，B 是否存在并行任务，合并冲突啥的。如果 D/A，D/B，D/C 这种 subspec 的形式，那么改动了 D/C subspec，就需要发布整个 D 组件，假如每个 subspec 的发布时间是 2 min，那么发布 D 组件的时间会 > 8min。

我们另外一个业务线的对外提供方式也是和你们一样，用的 subspec，后面都改成独立组件了。还有资源的话，你们没有跟着对应的组件走么？除了公用的那部分需要统一放在一个仓库里

njuxjy commented 5 years ago

跑了你的工程，都是OK的。最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。非常感谢

跑了你的工程，都是OK的。最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。非常感谢

如果 PodA 能把 subspec 铺平是最好的了，直接用插件生成，这样就不用模版 podspec。subspec 这东西，感觉很多时候比较鸡肋，会极大地增加 lint 耗时，即使改其中一个 subspec，还是需要对这个组件的所有 subspec 以及自身走 lint ，我们这边是把原来大部分 subspec 都拆成独立的工程了

我们PodA是个基础业务组件，用subspec主要用来切分resource，不同业务部门需要不同的resource就接不同的subspec，避免接入全量resource造成浪费。代码都是一套，所以我们的情况用subspec应该还好。我们这有些部门会对外输出一些能力，以单一Pod的形式输出比较方便接入方。这是个大而全的Pod，里面有很多子业务模块，都会频繁更新，都拆成独立Pod的话发版有点太频繁，依赖管理也有点麻烦，权衡下来他们都放一个Pod里，用subspec来切，有点mono repo的意思。然后不同subspec里定义不同的宏，接入方接入自己需要的subspec，其余subspec的代码不会参与编译。估计跟你那边情况不完全一样。

我的意思是这个发布这个大而全的 Pod 很耗时间。我们这边也会有对其他业务组输出业务组件的场景，基本上会创建一个壳组件，这个组件再设置所有输出的组件，外界依赖这个壳组件。好处是，假如我们有三个组件 A，B，C，这次只改了 C ，那么我只发布 C 就可以了，整个 CI 的 pipeline 很短，这对于动则15+个组件的发布来说，还是比较关键的，而且开发时只更改 C 壳工程即可，不用在意 A，B 是否存在并行任务，合并冲突啥的。如果 D/A，D/B，D/C 这种 subspec 的形式，那么改动了 D/C subspec，就需要发布整个 D 组件，假如每个 subspec 的发布时间是 2 min，那么发布 D 组件的时间会 > 8min。

我们另外一个业务线的对外提供方式也是和你们一样，用的 subspec，后面都改成独立组件了。还有资源的话，你们没有跟着对应的组件走么？除了公用的那部分需要统一放在一个仓库里

接入方接入的话是接多个独立组件对吧？资源的话我们其实是跟着组件走。举个例子吧，我们输出的业务组件X提供一些公共UI样式，还有针对不同接入方的多套皮肤。公共UI样式放X/Core subspec，其他皮肤放不同的subspec X/businessA, XbusinessB, ... 等，都依赖X/Core。接入方A就接 X/businessA 这样。

njuxjy commented 5 years ago

另外 CocoaPods/CocoaPods#8668 这个问题我之前也遇到过，我的临时解决办法是打完framework后把里面的Modules文件夹删除，SO上有人也这么做 https://stackoverflow.com/questions/38423565/include-of-non-modular-header-inside-framework-module-error

这么做的话就没有 moudlemap 文件了把，感觉这个文件还是需要的，能避免很多规范性问题

确实是把modulemap删了。暂时只能先删了，不然编译不过。回头再来查下是不是里面有些隐藏的小问题引起的。

我试了下如果A依赖B，A用framework，而B是源码的时候，A中import <B/B.h> 会报non-modular header的错误。用你的sample工程试了下好像也是这样。

ps: 你的sample里面 cocoapods_bin_issue_11_import_PodA.h 中 import了A，似乎应该改成 import B

tripleCC commented 5 years ago

跑了你的工程，都是OK的。最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。非常感谢

跑了你的工程，都是OK的。最后找到问题了，一个低级错误，PodA的源码podspec的依赖里把PodB漏了，所以源码接入PodA时找不到framework B了。当初在理PodA的依赖时只改了PodA.binary-template.podspec，漏改PodA.podspec了。非常感谢

如果 PodA 能把 subspec 铺平是最好的了，直接用插件生成，这样就不用模版 podspec。subspec 这东西，感觉很多时候比较鸡肋，会极大地增加 lint 耗时，即使改其中一个 subspec，还是需要对这个组件的所有 subspec 以及自身走 lint ，我们这边是把原来大部分 subspec 都拆成独立的工程了

我们PodA是个基础业务组件，用subspec主要用来切分resource，不同业务部门需要不同的resource就接不同的subspec，避免接入全量resource造成浪费。代码都是一套，所以我们的情况用subspec应该还好。我们这有些部门会对外输出一些能力，以单一Pod的形式输出比较方便接入方。这是个大而全的Pod，里面有很多子业务模块，都会频繁更新，都拆成独立Pod的话发版有点太频繁，依赖管理也有点麻烦，权衡下来他们都放一个Pod里，用subspec来切，有点mono repo的意思。然后不同subspec里定义不同的宏，接入方接入自己需要的subspec，其余subspec的代码不会参与编译。估计跟你那边情况不完全一样。

我的意思是这个发布这个大而全的 Pod 很耗时间。我们这边也会有对其他业务组输出业务组件的场景，基本上会创建一个壳组件，这个组件再设置所有输出的组件，外界依赖这个壳组件。好处是，假如我们有三个组件 A，B，C，这次只改了 C ，那么我只发布 C 就可以了，整个 CI 的 pipeline 很短，这对于动则15+个组件的发布来说，还是比较关键的，而且开发时只更改 C 壳工程即可，不用在意 A，B 是否存在并行任务，合并冲突啥的。如果 D/A，D/B，D/C 这种 subspec 的形式，那么改动了 D/C subspec，就需要发布整个 D 组件，假如每个 subspec 的发布时间是 2 min，那么发布 D 组件的时间会 > 8min。我们另外一个业务线的对外提供方式也是和你们一样，用的 subspec，后面都改成独立组件了。还有资源的话，你们没有跟着对应的组件走么？除了公用的那部分需要统一放在一个仓库里

接入方接入的话是接多个独立组件对吧？资源的话我们其实是跟着组件走。举个例子吧，我们输出的业务组件X提供一些公共UI样式，还有针对不同接入方的多套皮肤。公共UI样式放X/Core subspec，其他皮肤放不同的subspec X/businessA, XbusinessB, ... 等，都依赖X/Core。接入方A就接 X/businessA 这样。

是的，逻辑上接入的是多个独立组件，不过实际是通过一个壳组件间接引入所有依赖的组件。比如我们有表单组件，DataDrivenKit，并且有针对不同列表样式的表单元素，公用可编辑，公用不可编辑，然后有各个业务线专用的表单元素，这些都是放在不同仓库里面以不同的组件，而不是 subspec 接入。原先我们业务线少，没有进行区分，放在了一个大的 ItemComponents 组件里，业务线多了以后也是用 subspec 区分，但是这个组件里的样式越来越多以后， lint 的速度非常非常慢，每次发布这个组件都非常耗时。后面就把这个组件库拆分掉了，纵向拆成核心库，基础 Item 库，编辑库，不可编辑库，以及依赖这些库的各个线 Item 库，各个业务线 Item 库横向拆分（物理+逻辑上的），比如我所在的掌柜组，变更掌柜的 Item 库，只需要发布这个库就行，依赖的基础库都用二进制版本， lint 起来很快，其他业务线就发布他们自己的 Item 库，不影响掌柜的表单 UI 组件。有公用的 Item 就放在一个 CommonItem 库里面，不过这个库会有专人去 review 决定要不要合并

tripleCC commented 5 years ago

另外 CocoaPods/CocoaPods#8668 这个问题我之前也遇到过，我的临时解决办法是打完framework后把里面的Modules文件夹删除，SO上有人也这么做 https://stackoverflow.com/questions/38423565/include-of-non-modular-header-inside-framework-module-error

这么做的话就没有 moudlemap 文件了把，感觉这个文件还是需要的，能避免很多规范性问题

确实是把modulemap删了。暂时只能先删了，不然编译不过。回头再来查下是不是里面有些隐藏的小问题引起的。

我试了下如果A依赖B，A用framework，而B是源码的时候，A中import <B/B.h> 会报non-modular header的错误。用你的sample工程试了下好像也是这样。

ps: 你的sample里面 cocoapods_bin_issue_11_import_PodA.h 中 import了A，似乎应该改成 import B

嗯，这个是这样的，如果 A 二进制， B 源码，并且 A 有头文件 #import <B/B.h> 就会报这个错误，cocoapods 给 B 生成的 public header 是 B-umbrella.h ，modulemap 暴露的是这个文件， A 引用应该用 #import <B/B-umbrella.h>，并且因为 A 是 framework ，Enable Modules 没开，编译器没有把 #import <B/B.h> 替换成 @import B，所以会出现这个错误。如果把所有的 #import 替换成 @import 就没有这个问题

LoveLifeLoveSelf commented 4 years ago

您好，作者大神，最新版本能支持 archive、lint 、push 支持依赖多个私有源吗？

tripleCC / cocoapods-bin

pod bin archive时找不到私有源依赖 #11