3.17.1 Android CMake issue

3.17.1 Android CMake issue
0

@drelaptop not sure if this is 100% related to CMake, but I think since I’ve switched over to cmake I cant debug Android anymore, Failed to set breakpoint on Android Studio?

Does the Android CMake build require any special settings for debugging?

@drelaptop is it possible that COCOS2D_DEBUG isn’t defined correctly in the cmake android build?
for me it seems like it only get defined through the Android.mk files which isnt used when cmake is active right? Just noticed that since COCOS2D_DEBUG >= 1 doesn’t work anymore for android debug builds

it was defined here, a bug is COCOS2D_DEBUG was defined in release mode, otherwise doesn’t work.

Attention, COCOS2D_DEBUG macro is target related, not global. so the external source files without this macro defined.

1 Like

Android Studio itself uses ninja instead for make to build native codes. There is ninja execution program under Cmake folder, and some developers say Android Studio can not find ninja on windows. It is the Android Studio issue, you should set environment variable yourself if you meet the issue. The ninja path in my environment is

minggos-MacBook-Pro:bin minggo$ pwd
/Users/minggo/Library/Android/sdk/cmake/3.6.4111459/bin
minggos-MacBook-Pro:bin minggo$
minggos-MacBook-Pro:bin minggo$
minggos-MacBook-Pro:bin minggo$ ls ninja
ninja
2 Likes

@slackmoehrle i think we need to mention it in our doc.

@zhangxm sounds good. I’ll get it added to the install and FAQ of solutions.

EDIT: https://github.com/cocos2d/cocos2d-x-docs/pull/198

I met this issue when updating Android Studio’s CMake version to 3.10.2.4988404. And it seems it is the issue of CMake as somebody meets the same issue too. I fixed it by adding a symbol link like this:

minggos-MacBook-Pro:bin minggo$ sudo ln -s /Users/minggo/Library/Android/sdk/cmake/3.10.2.4988404/bin/ninja /usr/local/bin/ninja
1 Like

you can use try CMake 3.6

has anyone found a solution to enable automatic signing for iOS builds through cmake?

I use fastlane for my builds (Android and iOS). For the iOS build the lane will sign it correctly and match will download the provisioning profiles from Apple. It’s very easy with this setup.

Never heard about “fastlane” :thinking:
Are you talking about this: https://fastlane.tools/

1 Like

You can refer to the codes, just add

set_xcode_property(${APP_NAME} DEVELOPMENT_TEAM "")
set_xcode_property(${APP_NAME} CODE_SIGN_IDENTITY "iPhone Developer")

in CMakeLists.txt. As i tested, you just need to fill the DEVELOPMENT_TEAM.

1 Like

._.

I’ve tried something similar with the old engine few months back but used “iOS Developer” which didn’t work and it couldn’t find my Developer TeamID . but with “iPhone Developer” it seems to work.
I’ve also updated cmake since then, so probably one of those helped :slight_smile:

I’ll do some final tests including sdkbox so I can finally mark this as solved

You should fill the DEVELOPMENT_TEAM. You can find it in keychain:

  • open KeyChain Access
  • click Certificates
  • find the certificate, which is named iPhone Developer: xxx
  • right click it, and select Get Info
  • the value of Organizational Unit is the team id

yeah I already had inserted the correct ID back then where the issue was present, anyway it seems to be working now :slight_smile:

@drelaptop

Is it possible to crontroll Resource copying for all platfroms through cmake?
I’m not 100% sure whats possible for Android, since it also has gradle which handles some stuff.
I’m currently trying to exclude a Resources/Sound/IOS folder for example, entirely through CMake, but I guess this won’t be possible?

Currently I have to remove the folders in gradle directly in the android.applicationVariants.all section

    delete(fileTree(dir: variant.mergeAssets.outputDir, includes: ['platform/apple/**']))

I’m currently still playing around with going full cmake on my project :stuck_out_tongue:
I think nearly everything works now (all platforms, sdkbox, c++17)

I had one issue in one of the old posts: CMake GUI to generate iOS project

Where the CMake build resulted in displaying the app with an incorrect size (on my ipad), with my bad obj-c knowledge it turns out there is an option in XCode to set the app to IPhone,IPad and Universial :o


The default proj.ios_mac XCode project has this set to Universial, but the CMake project has it set to IPhone ._. , Setting it to Universial works, by adding this to the CMakeLists.txt

set_xcode_property(${APP_NAME} TARGETED_DEVICE_FAMILY “1,2”)

2 Likes

Is it currently only possible to run with Release and Debug instead of the CMake specific build types (including RelWithDebugInfo etc)
So using the predefined cmake build types or adding custom build types requires to change the engine
CocosConfigDefine.cmake file, which is a little bit annoying.

Currently I can only find the Debug option being disabled or enabled which automatically generates the CMAKE_CONFIGURATION_TYPE, so you can’t set the types your self, except you change it in the CocosConfigDefine.cmake

Or you changes the predefined CMAKE flags.

Let me know if there is another way.

In fact, you can’t switch build type to RelWithDebugInfo or something like.


One limit is just like you said CocosConfigDefine.cmake have finger it out clearly, that’s Debug and Release:

if(CMAKE_CONFIGURATION_TYPES)
    set(CMAKE_CONFIGURATION_TYPES "Debug;Release" CACHE STRING "Reset the configurations to what we need" FORCE)
    message(STATUS "CMAKE_CONFIGURATION_TYPES: ${CMAKE_CONFIGURATION_TYPES}")

Another is most of the prebuilt external libs existed only Release build, seldom existed Debug and Release, and no one using RelWithDebugInfo. For both build type we defined like:

if(WINDOWS)
  set_target_properties(${target_name} PROPERTIES
    # need use absolutely path
    IMPORTED_LOCATION_DEBUG "${platform_spec_path}/debug/lib${lib_name}.lib"
    IMPORTED_LOCATION_RELEASE "${platform_spec_path}/release/lib${lib_name}.lib"
  )
else()
  set_target_properties(${target_name} PROPERTIES
    IMPORTED_LOCATION "${platform_spec_path}/lib${lib_name}.a"
  )
endif()

By the way, may I ask why the RelWithDebugInfo is needed?

I’m currently having some issues on a apple release build where debug works fine. Therefore debug symbols would be great which are generated with -g . Atm I just add the flag to “Release” so it behaves like RelWithDebug. Obviously this resets when I create a new build, therefore isn’t the best solution.