背景
计划将改进后的CroNet单独开源给用户,让用户也能编译及调试,但部分代码不能开源(目前主要是包含加密算法的boringssl代码)。
因此,需要有一个开源方案,使得用户仅获取部分代码,但依然可以编译出包含完整功能的CroNet库。
解决思路
编译本质上是将代码翻译成机器可执行的二进制,因此在没有代码的情况下,直接提供二进制参与链接理论上是可行的。
因此该问题的解决思路是,将boringssl代码编译打包成libboringssl.a静态库,随代码库发布,用户使用时直接将libboringssl.a当做基础lib库。
技术难点
这里的技术难点主要是如何将libboringssl.a库以恰当的方式链接进最终产物。
在这之前,我们可以先产出一个不包含libboringssl.a的最终产物,做法是把boringssl的.cc代码都移除,只保留include头文件,再调整一下编译配置即可。
而最终如何发生链接的可行方案如下:
方案描述 | 优点 | 缺点 | 补充说明 |
---|---|---|---|
用户手动将libboringssl.a加入link列表中 | CroNet不需要过多改动 | 需要开源用户配合不同IDE、系统,进行最终链接方式不一样 | 例如编译iOS时,用户将CroNet.framework 与 libboringssl.a都添加到Xcode的link库配置中。 |
CroNet编译链接过程中,修改编译文件(.ninja)使其主动链接libboringssl.a | 对开源用户无感知 | 对CroNet改动较大实现方式比较trick,可能需要两次编译(编译过程同时修改编译文件可能不会对本次编译生效 | 由于编译阶段才会出现.ninja编译文件,并且我还需要获取当前的编译参数(如当前系统版本)决定链接哪个版本的libboringssl.a。因此只能在编译阶段触发某个脚本同时进行。 |
实现编译后置配置(ninja支持)在编译最后对libboringssl进行链接 | 对开源用户无感知 实现方式遵循ninja编译流程(相较上一个方案不那么trick) | 对CroNet改动较大 | ninja支持动态库使用libs= [“”]表示需要链接某个已存在的库,并支持action描述后置脚本动作,可用于静态库在最终阶段通过后置动作链接某个库 |
实际上方案2是在探索TurboNet自己链接方案的一个失败阶段,主要是方案比较trick结果又不完全符合预期,所以才重新构思了解决方案。
最终采用了第三个方案。
具体实现
|
|
收益点
提供了CroNet缺失部分代码情况下编译出完整功能的能力,解决了代码开源的关键问题。
做到了对用户透明,开关化灵活控制。