求教 IOS cmake 生成的 xcode工程分发

发行要求要IOS工程包,就是连带xcode工程一起的包进行分发,好替换证书出包。
但是现在cmake生成的工程包含绝对路径,引擎的路径又在工程外面,没法分发。
我尽量都是走的cmake或者脚本流程,不使用手动修改,好自动化构建工程包。但是各种问题。

试过几个方向:
1.拷贝需要的文件(引擎代码等)到proj目录下,并通过字符串替换 pbxproj 里面的绝对路径到相对路径。
不行,出现各种错误。
2.分离引擎工程,出一个单独的xcode project 给引擎,主工程引用引擎xcode project,方便仅仅对主工程进行处理。
通过add_subdirectory的方式加,没法分离源码树。
调用2次cmake生成2个工程,主工程的链接又混乱了,应该是没有执行引擎cmake里面的库链接。
3.cmake传入相对路径,或者用环境变量等
不行,相对路径进去cmake 会不认,工程的相对路径和某个cmake本身的相对路径也不一样。

不知道大家有没有这种经验。我弄了快2周了没弄好。连第一步移动工程文件夹位置都做不到,一移动不是这里红了就是那里红了。
就大致给一个比较容易点的方向,这个cmake的中间产物工程真的是挺难处理的。

我之前自己也在研究怎么实现ios自动构建打包,因为我这边会打无数的渠道包,查找了很多相关资料。fastlane,这个应该适合你。你的目的就是想同步证书自动打包,这个应该满足你,参考链接https://existorlive.github.io/2020/12/17/Fastlane.html

不是的,首先我们研发和发行是2个公司,最终打包证书和设备,都是在发行公司的,研发端是提供做好的xcode工程给发行,我们并没有证书和设备。
就是目前这个xcode工程是cmake生成的,移动位置和用其他机器打包,这个工程就会失效,所以发不出去给发行公司。目前是要解决这个问题。
以前cocos2d-x的时候是一个手工的xcode 工程,就没有这些问题。

你的意思是,你只想把xcode项目,发给发行公司,打包?我的理解,不应该是,你ios项目不应该是先拉取你当前release分支代码,然后执行构建导出,然后执行你的xcode项目构建,打包,导出ipa这个流程吗?你只发xcode proj项目,那你后续的什么bug修改,功能增加,又在发一份你build出来的pro项目给他们 ?因为,我这边打包,是远程链接的打包机,打包机会先git chekout我们最新分支出来,然后执行脚本构建打包

我们研发端,本身打ipa这套流程是完整的,用的我们测试证书,也是一键自动式的。
为什么要发xcode工程给发行,就是因为,我们如果直接发ipa过去,他们没办法以这个作为母包来替换他们的证书。android 我们可以发apk过去他们重签,ios的就不行了。
每次给他们发母包的时候,就发一个新的xcode工程就可以,他们直接打开这个工程做混淆,替换证书,就可以出包上传。

https://re-signing.github.io/ ,如果就是实现ipa重签,那有第三方的超级签 ,也有这种重签工具,就可以满足你的需求了吧

那是发行公司的需求,如果他们能用这个那是最好,那我就不需要这么麻烦了。但是目前的需求就是给工程。所以我们要出工程。
他们要用他们自己的设备,证书,还有混淆代码的流程。如果出马甲包,还要嵌入其他游戏等。

总之这个出工程的需求是不变的,在这个上面讨论是没什么意义,就是问怎么改cmake的工程让它可以移动。

我也相当讨厌cocos3.x这套原生功能机制。
贼鸡儿蠢,
真心不如cocos2.x和cocos2dx,
想不太明白。 好好的机制为什么要改。
而且改完之后。 整个论坛都在骂。

可以复制一份引擎文件到xcode工程里,然后修改xcode工程配置中引入cocos引擎的路径

这个只能解决引擎在工程外部的问题,没法解决绝对路径的问题。
除了引擎之外,其他资源类的也都是绝对路径。
另外,xcode工程内对引擎的引用,是每个cpp都引用绝对路径的。如果要修改路径,就要每个cpp都修改。

绝对路径的工程,你拷贝到另外的路径,或者放到另外的机器上(用户名不一样,路径不一样),就会失效,就没有分发性。

绝对路径的前缀可以变,比如使用SRCROOT + 拼接相对路径 ,去替换原来绝对路径引用

道理是这个道理。但是实际上cmake生成的工程,不是那么简单可以替换的,你可以试试看。
我试过2种方案:
1.去xcode project 下面的pbxproj文件里面,用字符串替换相对路径。
2.cmake传入的路径是相对路径。
全部失败,各种奇奇怪怪的问题。

字符串替换,只能替换xcode project的文件引用,还要字符串替换一些配置,包括projectDir本身就是绝对路径。cmake带有很多custom build step 和外部cmake脚本,这些的执行路径又不一样。这个方案弄了几天弄不下去了。

cmake 传入的路径是相对路径,这个很快就失败了,很多CMakeList.txt 引用失败,而且CMAKE_CURRENT_LIST_DIR 自动返回的是绝对路径。

这也不能手工改,几万个文件呢,光pbxproj文件就有30M,而且每次出包都要走过一次流程。
对了,引擎版本是3.7.3

不过这个也是没有办法的方案了。不能自动替换的细节地方非常多,如果硬磨,一个个位置改过来,也是有可能改好的。可以算成是一个保底方案吧。

做一个jenkins自动话打包就行了,换证书之类的都是自动化配置就行

我们本来就是jenkins自动化打包的,可以一键出ipa包(我们自己的测试证书),但正式发行的证书不在我们这,正式打包设备也不能是我们打包机(过包要换设备),发行那边要工程,所以我们要分发工程。

话说这个需求应该非常普遍吧? 独立的研发和发行合作做IOS,基本上都是证书和设备分离的,也方便马甲包。怎么好像大家都是自己直接出最终包一样?

特殊需求,特殊解决,去发行那里,给他们部署好xcode工程

或者写工程部署规范,所有xcode工程的依赖,指定具体目录

我感觉这个需求非常普遍的吧? 不算特殊需求,和各个发行合作基本上都是这个模式。

这个确实也算一种解决方案,就是让对方麻烦不少,用户名也要和我们打包机设置成一样,哈哈

这个难道不能和发行那边商榷一下? 直接每次xcode工程工作效率也低啊? 一般发行的这个无语需求,我这边都是拒绝的;直接会跟他们直属领导谈,然后他好了给他们专门在他们的机器上一次性做一套打包自动化,让他们随便换证书混淆;程序工作本身就很多很杂,无理要求,一般到我这就顶回去了,该满足的满足,不合理的无用功操作直接商榷给他们解决方案;

一点都不普遍,感觉这家发行的技术很弱,重签就好了,居然这么麻烦