New project creating with cocos v4 (cmake for everything)

New project creating with cocos v4 (cmake for everything)
0

I am going from v3 to v4. I currently have 3.15

If you create a new project, the xcodeproj does not exists and you have to create it with cmake. If you want to use this everytime it’s really time consuming.

And if you use external pods, it’s even worse.

We use a looot of pods, especially ad networks. sounds like a nightmare )

Yes, but once you use CMake for v3 and v4, that becomes a non-issue though, right? The reason is CMakeLists.txt will contain all the dependencies, and that is used to generate your project files. There won’t be any need to do a file comparison on project files, since they no longer exist, and everything is in the CMakeLists.txt (well with the exception of proj.android, where you should still check if any of the files have changed).

Regarding the pods, isn’t it possible to create a script to handle the installation of the pods after CMake creates the xcode project?

I know, that v4 is a breaking update and at an early stage - but we need a better documentation for migration into v4 or many of old engine users are lost with cmake (especially iOS/macOS, because Android is already on cmake - don’t know about Windows).

// cc @slackmoehrle How can we support the cocos team for that?

I’m 100% sure there are differences in the CMakeLists.txt between v3 and v4, since I have this section at the bottom of my file to support both v3 and v4 (something changed regarding resources etc):

get_target_property(COCOS2D_X_VERSION cocos2d VERSION)
message("Cocos2d Version ${COCOS2D_X_VERSION}")

if (COCOS2D_X_VERSION VERSION_GREATER 3.17.1)
    if(APPLE)
        set_target_properties(${APP_NAME} PROPERTIES RESOURCE "${APP_UI_RES}")
        if(MACOSX)
            set_target_properties(${APP_NAME} PROPERTIES
                                  MACOSX_BUNDLE_INFO_PLIST "${CMAKE_CURRENT_SOURCE_DIR}/proj.ios_mac/mac/Info.plist"
                                  )
        elseif(IOS)
            cocos_pak_xcode(${APP_NAME} INFO_PLIST "iOSBundleInfo.plist.in")
            set_xcode_property(${APP_NAME} ASSETCATALOG_COMPILER_APPICON_NAME "AppIcon")
            set_xcode_property(${APP_NAME} DEVELOPMENT_TEAM "")
            set_xcode_property(${APP_NAME} CODE_SIGN_IDENTITY "iPhone Developer")
        endif()
    elseif(WINDOWS)
        cocos_copy_target_dll(${APP_NAME})
    endif()

    if(LINUX OR WINDOWS)
        set(APP_RES_DIR "$<TARGET_FILE_DIR:${APP_NAME}>/Resources")
        cocos_copy_target_res(${APP_NAME} COPY_TO ${APP_RES_DIR} FOLDERS ${GAME_RES_FOLDER})
    endif()
else()
    if(APPLE)
        set_target_properties(${APP_NAME} PROPERTIES RESOURCE "${APP_UI_RES}")
        if(MACOSX)
            set_target_properties(${APP_NAME} PROPERTIES
                                  MACOSX_BUNDLE_INFO_PLIST "${CMAKE_CURRENT_SOURCE_DIR}/proj.ios_mac/mac/Info.plist"
                                  )
        elseif(IOS)
            cocos_pak_xcode(${APP_NAME} INFO_PLIST "iOSBundleInfo.plist.in")
            set_xcode_property(${APP_NAME} ASSETCATALOG_COMPILER_APPICON_NAME "AppIcon")
        endif()
    elseif(WINDOWS)
        cocos_copy_target_dll(${APP_NAME} COPY_TO ${APP_RES_DIR}/..)
    endif()

    if(LINUX OR WINDOWS)
        cocos_copy_res(COPY_TO ${APP_RES_DIR} FOLDERS ${GAME_RES_FOLDER})
    endif()
endif()

Windows is even easier than Android. I have this in a batch file that I check into source control with my project:

IF EXIST .\win32build\ GOTO STARTUPDATE
mkdir win32build
:STARTUPDATE
cd .\win32build
cmake .. -G"Visual Studio 16 2019" -Tv142 -A Win32
@REM cmake .. -G"Visual Studio 15 2017" -Tv141

I just run the batch file after checking out of source control, it creates the win32build folder, and inside it you’ll find the project solution file to open up in Visual Studio. Done.

I’ve done the same for the xcode project, and you can even test it using the cpp-tests. If you want to see how it all works, go into /tests/cpp-tests/, create a build folder, go into it, and run the CMake project generation for mac/ios, then open that project in Xcode and run it. It should work.

For Android I do nothing. It just works. And also for developing with CLion, I only open the CMakeList file. Sadly iOS/macOS is more complicated.

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

  1. Pod workspace with 15+ ad networks, analytics, attibution, crash reporting tools SDK.
  2. Many custom company solutions as mac targets to do specific jobs for the projects.
  3. Watch Target
  4. Stickers Target
  5. Many other SDK that are integarted manually without pods for each or our projects.
  6. Custom build phases created by us and some of our SDK for each of our projects.
  7. Custom build settings/preprocessor macros/ for each of our projects.
  8. Custom dependencies and capabilties.
  9. 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