yes to be honest i never used cmake ) usually we download cocos project, run download-deps, then run setup.py and then we generate new runnable project using cocos command.
cpp-test and cmake is a no brainer. Also the new created project with the help of https://github.com/cocos2d/cocos2d-x/tree/v4/cmake is possible, but we need a solution for upgrading an existing project.
I understand. There may be no way around the short term pain you are likely to go through in moving over to CMake, but once everything is set up correctly, then I can only say from my experience that it will be significantly easier to maintain moving forward.
1 Like
As far as I understand cmake. If I use it, I always have to use it to generate project files. Every change in the project files (settings), need to be reflected in cmake, so we can always generate them from scratch. This is a lot of overhead, right?
For example. Currently I use a custom script in my xcode build settings (switching GoogleService-Info.plist for different targets) - this has also to be included in cmake. Correct?
Within v3 I add that to xcodeproj and I’m good. We don’t need to touch anything else. But with v4 we had to change that.
So i have managed to install cmake and run it using instructions to create a new projects. However, i have no idea how to migrate now new structure into my existing 3.15 cocos project. @slackmoehrle Are you using v4 Metal currently? u want us to test v4 on our games ) Please provide us noob-style tutorials on how to migrate. And also what are your plans for the future?
1 Like
Once it’s set in CMake, then all future generated project files will have that setting, so you won’t need to set it manually.
That’s an interesting one, and I’m not sure how best to address it. Is it possible to create a script that runs and inserts the relevant fields in the CMake-generated xcode project? I haven’t yet moved to the macOS/iOS build of my application, so haven’t had to face these issues yet, but it looks like I’ll have to start thinking about this now.
1 Like
Yep, we should consider how developers migrate from old versions. That’s my plan of this issue:
- we will try to find solutions about using cmake with other tools, such as cocoapod, custom scripts using in Xcode, and we will write docs about how to migrate from old engine versions
- Developers can just use cmake to create cross platforms projects and use different projects as you do in v3 if cmake can not work with your custom settings. But engine will continue to use cmake as it will save us a lot work.
I am not sure if it works. So we need a list of issues caused by cmake, as far as the discussion, i know the issues:
- cmake work with cocoapod
- cmake with custom script added in xcodeproject
- how to migrate from old engine version (use 3.15 for example is enough?)
But @mars3142 could you please provide demos for the cocoapod and custom script? It will save us some time, thanks.
For my company, we have very large projects consisting of
- Pod workspace with 15+ ad networks, analytics, attibution, crash reporting tools SDK.
- Many custom company solutions as mac targets to do specific jobs for the projects.
- Watch Target
- Stickers Target
- Many other SDK that are integarted manually without pods for each or our projects.
- Custom build phases created by us and some of our SDK for each of our projects.
- Custom build settings/preprocessor macros/ for each of our projects.
- Custom dependencies and capabilties.
- Fastlane setups
Just a short list for what custom staff a project can hold. We should not be forced to migrate all of these for each project.
It makes more sense for us to create 1 cocos2d-x v4 project and copy all necessary files to our existing structure and apply necessary dependencies and build settings of cocos only to our existing projects. We are happy to do the same approach every time we need to update v4, but its a lot more work to do it the other way around for all our projects. If possible, include a tutorial on how to move v4 file to an existing 3.x project structure.
We should be able to just drag and drop the cmake generated folder right into an existing project (whatever the structure) and then just run some kind of script to apply any necessary modifications. We do this approach with some other SDK we use and it works perfectly. Their scripts add files to project, adds build phases, heade search paths etc without breakign anythign or requiring anything else.
I believe its far more difficulty trying to support all possible cases of incompatibilities as each project is unique. (speaking only about ios project)
1 Like
@kerryk i agree with you, i think we need a documentation for how to move v4 file to existing v3.x project structure.
Thanks for your understanding of the issue @zhangxm. Top suggestions by me are:
Use your existing cmake with some modifications to create project but without AppDelegate, RootViewController etc.
1.The previous structure is a cocos xcode project embeded in our own xcode project. Maybe we can just remove that and replace it with v4.
2. Similar to point 1, many use workspaces because of cocoa pods or other business logic. I guess it might also be possible to add it as parallel xcode project to our project in workspace, like cocoa pods is
added.
This way we get all necessary settings that are required by v4 etc and we keep our own. In addition, we still use cmake but a modified version of it. And we can have extra docs on what to remove/add to existing AppDelegate, AppController and RootViewController.
Does this sound like a plan?
1 Like
Yep, it makes sense.
Is it anything that engine should do? It seems the game project will set it, right?
1 Like
I guess if you support point 1, it will be compatible with point 2 as well, so it will depend on how the each programmer will want to setup it. ) Maybe there will be a few extra small steps but i dont think anything big.
1 Like
do we have any update on an easy way to use v4 on existing v3 project structure? 
Sorry, we don’t have time to write the doc. I think you can just modify cocos2d-x/CMakeLists.txt to generate xcode project for cocos. Just comment the codes
# prevent tests project to build "cocos2d-x/cocos" again
set(BUILD_ENGINE_DONE ON)
# add cpp tests default
add_subdirectory(${COCOS2DX_ROOT_PATH}/tests/cpp-empty-test ${ENGINE_BINARY_PATH}/tests/cpp-empty-test)
add_subdirectory(${COCOS2DX_ROOT_PATH}/tests/cpp-tests ${ENGINE_BINARY_PATH}/tests/cpp-tests)
if(BUILD_LUA_LIBS)
add_subdirectory(${COCOS2DX_ROOT_PATH}/tests/lua-empty-test/project ${ENGINE_BINARY_PATH}/tests/lua-empty-test)
add_subdirectory(${COCOS2DX_ROOT_PATH}/tests/lua-tests/project ${ENGINE_BINARY_PATH}/tests/lua-test)
endif(BUILD_LUA_LIBS)
# add cpp-template-default into project(Cocos2d-x) for tmp test
Of course, you should link libraries needed if your app’s Xcode project.
We are writing the docs about how to upgrade v3 project to v4, will be finished in days. The news is that, it works on macos now, and is testing for iOS now.
@kerryk @zhangxm here is a guide for you to migrate v4 engine into your existing v3 project. It can work for both iOS and macOS. A problem is that you have to manual apply the changes to your project according to the guide. Because there is no a script for you to do automatically modifications to the xcode project. I don’t know how to do it. Any advice or examples that I can fix this problem?
Thanks! i will have a look at this guide! @zhangxm if possible after you finish your v3 -> v4, improve also the v4 -> v3 a video guide would be really nice addition!
My cocos2d-x/build/engine/cocos/core/ path looks empty, there is no xcode project there, i have a project only inside external. How does yours look like?
EDIT: Nevermind, i probably had old version of v4. I re-download and all good. Will continue the guide.
Something that i yet do not understand. I use cmake to make the initial ios project inside ios-build and cocos2d-x xcode project for v4 can compile fine. Why if i move the entire cocos2d-x directory somewhere else, e.g. inside my project after i make initial cmake cocos2d-x does not compile anymore. seems that cmake uses old directory or something… as it keeps creating a cocos2d-x folder in the old path.