Hello I just recently made the jump to 3.17.1 which uses cmake , i use to add arm64-v8a to Application.mk but to my knowledge application.mk is no longer being used in 3.17.1 (correct me if im wrong) ?
If you opened up /proj.android/app/build.gradle, you would have seen a trail that would have led you to gradle.properties, and in there you would have seen this:
# List of CPU Archtexture to build that application with
# Available architextures (armeabi-v7a | arm64-v8a | x86)
# To build for multiple architexture, use the `:` between them
# Example - PROP_APP_ABI=armeabi-v7a:arm64-v8a:x86
PROP_APP_ABI=armeabi-v7a:arm64-v8a:x86
Don’t be afraid to open up the files in the project folders to find out what purpose they serve, because the answers could be right there waiting for you to find them.
1 Like
Ok thanks very much! This is the only file I have to add the architectures to ?
Yes, that’s the only file you need to adjust. Just in case you don’t know this already, you should open up proj.android/app/build.gradle, read through it, and learn how it works. If you’re going to be developing for Android, then you really should learn all the parts that are relevant to what you need, and how everything fits together.
1 Like
Will definitely be doing this ! Thanks again for your insight
The only bad issue with this is, that you can’t compile for x64 right now. And Google requires 64 bit in 2019 for all new/updated apps. Hope cocos2d-x will remove prebuilts soon, so we can compile against all ABIs we want.
1 Like
What about arm64-v8a ?
cocos2d and sdkbox support it.
isnt arm64-v8a the same as x64?
Not same but arm64-v8a and arm is like x64 and x86
1 Like
You’re talking about external libraries, correct? If so, then there are 2 ways to fix it. The 64 bit pre-built libraries should be provided for each platform, or we get the source code and compile it at build time. Either way works, although there is always the risk with pre-built libraries, since they may not be binary compatible with whichever compiler/linker we’re using.
2 Likes
Correct and build it on your own development environment has also the benefit, that you can change the 3rd party libs if needed or just for debugging purpose.
And because build tools are working incremental, they will never do a full recompile. Only if you change branches (if you use a git/svn/whatever - you should) or you do a clean build, so there is no argument for prebuilts these days anymore.
2 Likes
which external libraries are you guys referring to, ones that come bundled with Cocos2d-x? and dont you have to explicitly set the libraries to be pre built as stated here (https://docs.cocos2d-x.org/cocos2d-x/en/editors_and_tools/prebuilt_libraries.html) ?
We’re referring to the libraries like the ones located in the [cocos_root_folder]/external/ folder.
That information at that link is related to building the Cocos2d engine as a library so you don’t need to keep recompiling it every time you do a clean/build. I’m not sure if the information is even relevant any more, since pre-building of the engine source code has been removed as of 3.17.1.
1 Like
makes sense, maybe theyll be updating the docs soon