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

Creator 3.x
#21

其实这个需求本身我觉得问题不大的，他们拿到工程自定义空间也大。
以前cocos2d-x 的时候，给工程很方便的，只是现在creator 用了cmake 以后，给工程就复杂了。
所以当然是延续这个需求了，不能因为换了引擎导致需求变的麻烦。

#22

重签自定义空间小啊，apk可以重签，是因为安卓容易过包。ios的过包自定义的东西比较多点。

#23

我现在有一个新的思路，就是直接把cmake本身和工程一起分发给他们，再给他们一个脚本重新用cmake generate 一次，把路径重定向到他们机器的路径，这种应该是比较简单了。

#24

也是，主要问题就是 CocosCreator3.x系列之后 工程导出原生确实很恶心人！官方刻意把引擎一些路径绑定死到cmake里；在增加了 非官方人员 将新版CocosCreator3.x引擎系列内嵌到纯原生安卓和iOS应用内的工作量和难度；安卓还好处理一点，但是iOS确实费劲，一方面是xcode工程内部引擎的要几乎重引入，另一方面就是但拎出来引擎的一些cmake写的绝对逻辑让人头大； 我前端时间自定义CocosCreator3.8.3引擎想做多渠道自定义打包不想受目前Cocos的这个导出工程目录的限制，就浪费了一天的时间搞这些；。。。。 其实从目前cmake的这堆问题来看，要么是官方刻意留的坑为他们的付费service做嫁衣；要么就是 目前新招的这一批技术能力差点意思自身对cmake理解就不行对嵌入式的那套c的东西搞得不太明白；说实话从cmake的里面的一些结构梳理上看我个人认为大概率是这批技术技术能力差点意思还需要再推敲优化；

#25

目前大家给的方案有：
1.引擎移到工程里面，然后替换相对路径
试过工作量比较大，不能自动化修改的细节很多，但是一点点改应该能改出来。

2.给发行机器直接对应环境，部署规范
这样就是发行那边比较麻烦，路径要全部对应，甚至用户名也要一样，不过弄好了是可以的。

3.直接分发cmake和脚本给发行，让他们运行以纠正路径。
这个刚想到，要试一下可以不可以。不过应该是比较简单的。

1赞
#26

楼主有没有探索出更好的办法，求分享

#27

目前是直接分发cmake的，做了一个rerun_cmake.sh 和cmake一起放到工程包里面，发行拿到以后，直接运行一下那个sh，再打开工程就对了。

1赞
#28

这样做的前提还是发行那边要先安装对应的cocos引擎版本吗

#29

不需要啊，xcode的工程里面就直接带有引擎部分的代码了。
我们在打包的时候，修改了脚本，让引擎的路径引用到工程下的目录，然后对应目录建立到引擎代码的软连接。打包工程的时候，zip一下就直接把引擎的代码全部打进去了。

#30

@dumganhar 引擎组是否考虑下，打包时引擎直接打包成.a/.so 文件（应该做成可选，调试时还是用源码），不然现在分发确实不方便

#31

3.x 版本暂无此计划。 4.x 可以考虑下。

#32

请教一下这一块是改了哪些文件呢

#33

我们现在也是想先尝试手动改的，还是会有报错，找起来真的麻烦

#34

这是cmake在我们打包系统里面调用的命令。
（我们的打包系统是python脚本，辅助使用cocos creator的命令行，这里的步骤是在使用cocos creator命令行构建完成后，再执行cmake进行一些路径修改）

cmake_cmd = [cmake_path,"-S",os.path.join(project_native_link_dir,"ios"),"-B",ios_proj_path,f"-DRES_DIR={ios_proj_path}",f"-DPROJ_DIR={ios_proj_path}",\ f"-DCUSTOM_COCOS_X_PATH={engine_native_link_dir}",\ "-G", "Xcode", "-T","buildsystem=12","-DCMAKE_SYSTEM_NAME=iOS","-DCMAKE_CXX_COMPILER=clang++","-DCMAKE_C_COMPILER=clang",\ "-DAPP_NAME=main","-DLAUNCH_TYPE=Release"]

那个 engine_native_link_dir 就是软链接引擎的位置，是在工程目录下。
设置软链接的代码是：

#engine native
engine_native_path = “”
engine_native_link_dir = os.path.join(ios_proj_path,“native”);
if engine_path_custom and os.path.exists(engine_path_custom):
engine_native_path = os.path.join(engine_path_custom,“native”)
else :
engine_native_path = cocos_creator_path.replace(“MacOS/CocosCreator”,“Resources/resources/3d/engine/native”);
if os.path.exists(engine_native_path) and (not os.path.exists(engine_native_link_dir)):
os.symlink(engine_native_path, engine_native_link_dir);
else :
print(“engine_native_path not exists, please check the engine_path_custom in build.py”)

cmake改路径的话，就是在CMakeLists.txt 那层级里面改了。 加入一个CUSTOM_COCOS_X_PATH 的变量，代替掉里面指向COCOS的路径。
在native/engine/common里面的CMakeList.txt 里面：

if(NOT COCOS_X_PATH)
message(FATAL_ERROR “COCOS_X_PATH is not set!”)
endif()

if(DEFINED CUSTOM_COCOS_X_PATH)
set(COCOS_X_PATH “${CUSTOM_COCOS_X_PATH}”)
endif()

不直接使用COCOS_X_PATH这个变量，另外定义一个是有原因的，但是我忘记了为什么。

#35

之前没实际接触过cmake，所以看得有点一知半解，谢谢哈，根据你这个我们再往下研究

#36

我也遇到了这个问题 别的都可以分离 但是只要把工程给到发行去融合 因为是绝对路径 怎么改都不对 各种缺东西 你们最后是怎么解决的

#37

这个是具体怎么做的 对cmake也不太了解

#38

给发行的时候，带一个脚本，和cmake工具，让他们重新运行一次cmake就可以了。不过你打包的时候要拷贝相关内容（例如引擎）到工程目录下。
rerun_cmake.sh

#!/bin/bash

# Get the absolute path of the script's directory
current_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"

# Set the path to cmake in the current directory
cmake_path="${current_dir}/cmake/bin/cmake"

# Ensure the cmake binary has executable permissions
if [ ! -x "$cmake_path" ]; then
    chmod +x "$cmake_path"
fi

# Delete CMakeCache.txt in the current directory
if [ -f "$current_dir/CMakeCache.txt" ]; then
    rm "$current_dir/CMakeCache.txt"
fi

# Execute cmake with the specified command line options
"$cmake_path" -S "${current_dir}/project_native/ios" -B "${current_dir}" \
    -DRES_DIR="${current_dir}" \
    -DPROJ_DIR="${current_dir}" \
    -DCUSTOM_COCOS_X_PATH="${current_dir}/native" \
    -G "Xcode" \
    -T "buildsystem=12" \
    -DCMAKE_SYSTEM_NAME=iOS \
    -DCMAKE_CXX_COMPILER=clang++ \
    -DCMAKE_C_COMPILER=clang \
    -DAPP_NAME=main \
    -DLAUNCH_TYPE=Release

给工程包的时候，每次让他们在本地设备上运行一下这个脚本，重新执行cmake，工程路径就会矫正好了。

#39

好的 感谢大佬